| |
| RFC 1900 | Renumbering Needs Work |
| |
| Authors: | B. Carpenter, Y. Rekhter. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1900 |
|
Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes. |
|
| |
| RFC 1901 | Introduction to Community-based SNMPv2 |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1901 |
|
The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community. |
|
| |
| RFC 1902 | Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1442 |
| Obsoleted by: | RFC 2578 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1902 |
|
It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] |
|
| |
| RFC 1903 | Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1443 |
| Obsoleted by: | RFC 2579 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1903 |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 1904 | Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1444 |
| Obsoleted by: | RFC 2580 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1904 |
|
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] |
|
| |
| RFC 1905 | Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1448 |
| Obsoleted by: | RFC 3416 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1905 |
|
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] |
|
| |
| RFC 1906 | Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1449 |
| Obsoleted by: | RFC 3417 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1906 |
|
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] |
|
| |
| RFC 1907 | Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1450 |
| Obsoleted by: | RFC 3418 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1907 |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1908 | Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1452 |
| Obsoleted by: | RFC 2576 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1908 |
|
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK] |
|
| |
| RFC 1909 | An Administrative Infrastructure for SNMPv2 |
| |
| Authors: | K. McCloghrie, Ed.. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1909 |
|
It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1910 | User-based Security Model for SNMPv2 |
| |
| Authors: | G. Waters, Ed.. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1910 |
|
In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1911 | Voice Profile for Internet Mail |
| |
|
|
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1912 | Common DNS Operational and Configuration Errors |
| |
|
|
This memo describes errors often found in both the operation ofDomain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537]. |
|
| |
| RFC 1913 | Architecture of the Whois++ Index Service |
| |
| Authors: | C. Weider, J. Fullton, S. Spero. |
| Date: | February 1996 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1913 |
|
The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. |
|
| |
| RFC 1914 | How to Interact with a Whois++ Mesh |
| |
| Authors: | P. Faltstrom, R. Schoultz, C. Weider. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1914 |
|
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK] |
|
| |
| RFC 1915 | Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol |
| |
|
|
The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1916 | Enterprise Renumbering: Experience and Information Solicitation |
| |
| Authors: | H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. |
| Date: | February 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1916 |
|
Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. To this end the working group is soliciting information from organizations that already have gone through, or are in the process of going through, renumbering efforts. Case studies, tools, and lists of applications that require special attention are sought. |
|
| |
| RFC 1917 | An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA |
| |
|
|
This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to theInternet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment. |
|
| |
| RFC 1918 | Address Allocation for Private Internets |
| |
|
|
This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1919 | Classical versus Transparent IP Proxies |
| |
| Authors: | M. Chatel. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1919 |
|
Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. |
|
| |
| RFC 1920 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1921 | TNVIP Protocol |
| |
| Authors: | J. Dujonc. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1921 |
|
The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. |
|
| |
| RFC 1922 | Chinese Character Encoding for Internet Messages |
| |
| Authors: | HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. |
| Date: | March 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1922 |
|
This memo describes methods of transporting Chinese characters inInternet services which transport text, such as electronic mail[RFC-822], network news [RFC-1036], telnet [RFC-854] and the WorldWide Web [RFC-1866]. |
|
| |
| RFC 1923 | RIPv1 Applicability Statement for Historic Status |
| |
| Authors: | J. Halpern, S. Bradner. |
| Date: | March 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1923 |
|
RIP Version 1 [RFC-1058] has been declared an historic document.This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is theClassful nature of RIPv1. |
|
| |
| RFC 1924 | A Compact Representation of IPv6 Addresses |
| |
| Authors: | R. Elz. |
| Date: | 1 April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1924 |
|
This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1925 | The Twelve Networking Truths |
| |
| Authors: | R. Callon. |
| Date: | 1 April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1925 |
|
This memo documents the fundamental truths of networking for theInternet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. |
|
| |
| RFC 1926 | An Experimental Encapsulation of IP Datagrams on Top of ATM |
| |
| Authors: | J. Eriksson. |
| Date: | 1 April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1926 |
|
This RFC describes a method of encapsulating IP datagrams on top ofAcoustical Transmission Media (ATM). This is a non-recommended standard. Distribution of this memo is unnecessary. |
|
| |
| RFC 1927 | Suggested Additional MIME Types for Associating Documents |
| |
| Authors: | C. Rogers. |
| Date: | 1 April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1927 |
|
Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1928 | SOCKS Protocol Version 5 |
| |
| Authors: | M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1928 |
|
This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] |
|
| |
| RFC 1929 | Username/Password Authentication for SOCKS V5 |
| |
| Authors: | M. Leech. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1929 |
|
The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK] |
|
| |
| RFC 1930 | Guidelines for creation, selection, and registration of an Autonomous System (AS) |
| |
|
|
This memo discusses when it is appropriate to register and utilize anAutonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior GatewayProtocol, now at historical status; see [EGP]), BGP (Border GatewayProtocol, the current de facto standard for inter-AS routing; see[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which theInternet is expected to adopt when BGP becomes obsolete; see [IDRP]).It should be noted that the IDRP equivalent of an AS is the RDI, orRouting Domain Identifier. |
|
| |
| RFC 1931 | Dynamic RARP Extensions for Automatic Network Address Acquisition |
| |
| Authors: | D. Brownell. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1931 |
|
This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind. |
|
| |
| RFC 1932 | IP over ATM: A Framework Document |
| |
| Authors: | R. Cole, D. Shur, C. Villamizar. |
| Date: | April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1932 |
|
It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1933 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
| Authors: | R. Gilligan, E. Nordmark. |
| Date: | April 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1933 |
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. |
|
| |
| RFC 1934 | Ascend's Multilink Protocol Plus (MP+) |
| |
| Authors: | K. Smith. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1934 |
|
This document proposes an extension to the PPP Multilink Protocol(MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. |
|
| |
| RFC 1935 | What is the Internet, Anyway? |
| |
| Authors: | J. Quarterman, S. Carl-Mitchell. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1935 |
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1936 | Implementing the Internet Checksum in Hardware |
| |
| Authors: | J. Touch, B. Parham. |
| Date: | April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1936 |
|
This memo presents a techniques for efficiently implementing theInternet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. |
|
| |
| RFC 1937 | "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks |
| |
| Authors: | Y. Rekhter, D. Kandlur. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1937 |
|
The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM,Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network. The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. |
|
| |
| RFC 1938 | A One-Time Password System |
| |
|
|
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK] |
|
| |
| RFC 1939 | Post Office Protocol - Version 3 |
| |
|
|
The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK] |
|
| |
| RFC 1940 | Source Demand Routing: Packet Format and Forwarding Specification (Version 1) |
| |
| Authors: | D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1940 |
|
The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1941 | Frequently Asked Questions for Schools |
| |
|
|
The goal of this FYI document, produced by the Internet SchoolNetworking (ISN) group in the User Services Area of the InternetEngineering Task Force (IETF), is to act as an introduction to theInternet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing theInternet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools. Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States. |
|
| |
| RFC 1942 | HTML Tables |
| |
|
|
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context. |
|
| |
| RFC 1943 | Building an X.500 Directory Service in the US |
| |
| Authors: | B. Jennings. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1943 |
|
This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the UnitedStates. This project is the work performed for the IntegratedDirectory Services Working Group within the Internet Engineering TaskForce, for establishing an electronic White Pages Directory Service within an organization in the US and for connecting it to a wide-areaDirectory infrastructure.
Establishing a successful White Pages Directory Service within an organization requires a collaborative effort between the technical, legal and data management components of an organization. It also helps if there is a strong commitment from the higher management to participate in a wide-area Directory Service.
The recommendations presented in the document are the result of experience from participating in the Internet White Pages project. |
|
| |
| RFC 1944 | Benchmarking Methodology for Network Interconnect Devices |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 1945 | Hypertext Transfer Protocol -- HTTP/1.0 |
| |
| Authors: | T. Berners-Lee, R. Fielding, H. Frystyk. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1945 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature ofHTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0". |
|
| |
| RFC 1946 | Native ATM Support for ST2+ |
| |
| Authors: | S. Jackowski. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1946 |
|
As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).
The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)
Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.
This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:
- ATM to internet,- internet to ATM, and- internet to internet across ATM. |
|
| |
| RFC 1947 | Greek Character Encoding for Electronic Mail Messages |
| |
| Authors: | D. Spinellis. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1947 |
|
This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1948 | Defending Against Sequence Number Attacks |
| |
|
|
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. |
|
| |
| RFC 1949 | Scalable Multicast Key Distribution |
| |
| Authors: | A. Ballardie. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1949 |
|
The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of theMBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.
Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.
This memo provides a scalable solution to the multicast key distribution problem.
NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B. |
|
| |
| RFC 1950 | ZLIB Compressed Data Format Specification version 3.3 |
| |
|
|
This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it. |
|
| |
| RFC 1951 | DEFLATE Compressed Data Format Specification version 1.3 |
| |
|
|
This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents. |
|
| |
| RFC 1952 | GZIP file format specification version 4.3 |
| |
|
|
This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents. |
|
| |
| RFC 1953 | Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1953 |
|
The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow. The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3. |
|
| |
| RFC 1954 | Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1954 |
|
This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. |
|
| |
| RFC 1955 | New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG |
| |
| Authors: | R. Hinden. |
| Date: | June 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1955 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden. It was originally sent as an email message. It proposes a medium term solution to theInternet's routing and addressing problems. |
|
| |
| RFC 1956 | Registration in the MIL Domain |
| |
| Authors: | D. Engebretson, R. Plzak. |
| Date: | June 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1956 |
|
This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1957 | Some Observations on Implementations of the Post Office Protocol (POP3) |
| |
|
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1958 | Architectural Principles of the Internet |
| |
|
|
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. |
|
| |
| RFC 1959 | An LDAP URL Format |
| |
|
|
This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1960 | A String Representation of LDAP Search Filters |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 1961 | GSS-API Authentication Method for SOCKS Version 5 |
| |
| Authors: | P. McMahon. |
| Date: | June 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1961 |
|
This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK] |
|
| |
| RFC 1962 | The PPP Compression Control Protocol (CCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.
This document defines a method for negotiating data compression overPPP links. |
|
| |
| RFC 1963 | PPP Serial Data Transport Protocol (SDTP) |
| |
| Authors: | K. Schneider, S. Venters. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1963 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120 [2]. |
|
| |
| RFC 1964 | The Kerberos Version 5 GSS-API Mechanism |
| |
|
|
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK] |
|
| |
| RFC 1965 | Autonomous System Confederations for BGP |
| |
|
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.
The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
The extension this document describes is widely deployed in theInternet today. |
|
| |
| RFC 1966 | BGP Route Reflection An alternative to full mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 1967 | PPP LZS-DCP Compression Protocol (LZS-DCP) |
| |
| Authors: | K. Schneider, R. Friend. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1967 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP(Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol. |
|
| |
| RFC 1968 | The PPP Encryption Control Protocol (ECP) |
| |
| Authors: | G. Meyer. |
| Date: | June 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1968 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.
This document defines a method for negotiating data encryption overPPP links. |
|
| |
| RFC 1969 | The PPP DES Encryption Protocol (DESE) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. |
|
| |
| RFC 1970 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2461 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1970 |
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 1971 | IPv6 Stateless Address Autoconfiguration |
| |
| Authors: | S. Thomson, T. Narten. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1971 |
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. |
|
| |
| RFC 1972 | A Method for the Transmission of IPv6 Packets over Ethernet Networks |
| |
|
|
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK] |
|
| |
| RFC 1973 | PPP in Frame Relay |
| |
| Authors: | W. Simpson. |
| Date: | June 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1973 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing PPP encapsulated packets. |
|
| |
| RFC 1974 | PPP Stac LZS Compression Protocol |
| |
| Authors: | R. Friend, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1974 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. |
|
| |
| RFC 1975 | PPP Magnalink Variable Resource Compression |
| |
| Authors: | D. Schremp, J. Black, J. Weiss. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1975 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links.
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. |
|
| |
| RFC 1976 | PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) |
| |
| Authors: | K. Schneider, S. Venters. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1976 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a standard method for encapsulating and transporting serial data over aPPP link. The PPP Compression Control Protocol [3] provides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-TerminatingEquipment (DCE). |
|
| |
| RFC 1977 | PPP BSD Compression Protocol |
| |
| Authors: | V. Schryver. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1977 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. |
|
| |
| RFC 1978 | PPP Predictor Compression Protocol |
| |
| Authors: | D. Rand. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1978 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method for transporting multi-protocol datagrams over PPP encapsulated links.
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. |
|
| |
| RFC 1979 | PPP Deflate Protocol |
| |
| Authors: | J. Woods. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1979 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. |
|
| |
| RFC 1980 | A Proposed Extension to HTML : Client-Side Image Maps |
| |
|
|
The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations. |
|
| |
| RFC 1981 | Path MTU Discovery for IP version 6 |
| |
| Authors: | J. McCann, S. Deering, J. Mogul. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8201 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1981 |
|
This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery forIP version 4. |
|
| |
| RFC 1982 | Serial Number Arithmetic |
| |
|
|
This memo defines serial number arithmetic, as used in the DomainName System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in anIETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. |
|
| |
| RFC 1983 | Internet Users' Glossary |
| |
|
|
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them. |
|
| |
| RFC 1984 | IAB and IESG Statement on Cryptographic Technology and the Internet |
| |
|
|
The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1985 | SMTP Service Extension for Remote Message Queue Starting |
| |
| Authors: | J. De Winter. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1985 |
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers. |
|
| |
| RFC 1986 | Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) |
| |
| Authors: | W. Polites, W. Wollman, D. Woo, R. Langan. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1986 |
|
This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1987 | Ipsilon's General Switch Management Protocol Specification Version 1.1 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | August 1996 |
| Formats: | txt html json |
| Updated by: | RFC 2297 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1987 |
|
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. |
|
| |
| RFC 1988 | Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework |
| |
| Authors: | G. McAnally, D. Gilbert, J. Flick. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1988 |
|
This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1989 | PPP Link Quality Monitoring |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.
This document defines a protocol for generating Link-Quality-Reports. |
|
| |
| RFC 1990 | The PPP Multilink Protocol (MP) |
| |
| Authors: | K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1717 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1990 |
|
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.
The differences between the current PPP Multilink specification (RFC1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations. |
|
| |
| RFC 1991 | PGP Message Exchange Formats |
| |
| Authors: | D. Atkins, W. Stallings, P. Zimmermann. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4880 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1991 |
|
This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1992 | The Nimrod Routing Architecture |
| |
| Authors: | I. Castineyra, N. Chiappa, M. Steenstrup. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1992 |
|
We present a scalable internetwork routing architecture, calledNimrod. The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction. |
|
| |
| RFC 1993 | PPP Gandalf FZA Compression Protocol |
| |
| Authors: | A. Barbir, D. Carr, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1993 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. |
|
| |
| RFC 1994 | PPP Challenge Handshake Authentication Protocol (CHAP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. |
|
| |
| RFC 1995 | Incremental Zone Transfer in DNS |
| |
|
|
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. |
|
| |
| RFC 1996 | A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) |
| |
|
|
This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. |
|
| |
| RFC 1997 | BGP Communities Attribute |
| |
|
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets.
This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers.
The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet. |
|
| |
| RFC 1998 | An Application of the BGP Community Attribute in Multi-home Routing |
| |
| Authors: | E. Chen, T. Bates. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1998 |
|
This document presents an application of the BGP community attribute[2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today. Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity. |
|
| |
| RFC 1999 | Request for Comments Summary RFC Numbers 1900-1999 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1999 |
|
|
|
