| |
| RFC 2100 | The Naming of Hosts |
| |
| Authors: | J. Ashworth. |
| Date: | 1 April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2100 |
|
This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2101 | IPv4 Address Behaviour Today |
| |
| Authors: | B. Carpenter, J. Crowcroft, Y. Rekhter. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2101 |
|
The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. |
|
| |
| RFC 2102 | Multicast Support for Nimrod : Requirements and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2102 |
|
Nimrod does not specify a particular solution for multicasting.Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast(PIM) protocol. |
|
| |
| RFC 2103 | Mobility Support for Nimrod : Challenges and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2103 |
|
We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support.We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol. |
|
| |
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication |
| |
| Authors: | H. Krawczyk, M. Bellare, R. Canetti. |
| Date: | February 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6151 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2104 |
|
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function. |
|
| |
| RFC 2105 | Cisco Systems' Tag Switching Architecture Overview |
| |
| Authors: | Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2105 |
|
This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described. |
|
| |
| RFC 2106 | Data Link Switching Remote Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2114 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2106 |
|
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com. |
|
| |
| RFC 2107 | Ascend Tunnel Management Protocol - ATMP |
| |
| Authors: | K. Hamzeh. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2107 |
|
This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. The user's client software uses an address contained in the home network address space for the remote access. Packets to and from the home network are tunneled by the Network Access Server (NAS) to which the user connects and a Home Agent (HA) on the user's home network. This allows for the support of access to Virtual Private Networks and also allows for the use of protocols other than IP to be carried over the tunnel. An example of how the RADIUS (Remote Authentication Dial InUser Service) can be used to provide the necessary configuration information to support this service is also provided. |
|
| |
| RFC 2108 | Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 |
| |
| Authors: | K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. |
| Date: | February 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 1516 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2108 |
|
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 10 and 100Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10& 100 Mb/s Management," October 26, 1995. |
|
| |
| RFC 2109 | HTTP State Management Mechanism |
| |
|
|
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK] |
|
| |
| RFC 2110 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| |
| Authors: | J. Palme, A. Hopmann. |
| Date: | March 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2557 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2110 |
|
Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base". |
|
| |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators |
| |
|
|
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. |
|
| |
| RFC 2112 | The MIME Multipart/Related Content-type |
| |
|
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 2113 | IP Router Alert Option |
| |
|
|
This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path. |
|
| |
| RFC 2114 | Data Link Switching Client Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 2106 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2114 |
|
This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to dcap@cisco.com. |
|
| |
| RFC 2115 | Management Information Base for Frame Relay DTEs Using SMIv2 |
| |
|
|
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 Frame Relay interfaces on DTEs. [STANDARDS-TRACK] |
|
| |
| RFC 2116 | X.500 Implementations Catalog-96 |
| |
|
|
This document is a revision to [RFC 1632]: A Revised Catalog ofAvailable X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations ofX.500, including commercial products and openly available offerings.[RFC 1632] is a revision of [RFC 1292]. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.
This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 2117 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2362 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2117 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2118 | Microsoft Point-To-Point Compression (MPPC) Protocol |
| |
| Authors: | G. Pall. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2118 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointCompression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. |
|
| |
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| |
|
|
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: |
|
| |
| RFC 2120 | Managing the X.500 Root Naming Context |
| |
| Authors: | D. Chadwick. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2120 |
|
The X.500 Standard [X.500 93] has the concept of first level DSAs, whose administrators must collectively manage the root naming context through bi-lateral agreements or other private means which are outside the scope of the X.500 Standard.
The NameFLOW-Paradise X.500 service has an established procedure for managing the root naming context, which currently uses Quipu proprietary replication mechanisms and a root DSA. The benefits that derive from this are twofold:
- firstly it is much easier to co-ordinate the management of the root context information, when there is a central point of administration,
- secondly the performance of one-level Search operations is greatly improved because the Quipu distribution and replication mechanism does not have a restriction that exists in the 1988 and1993 X.500 Standard.
The NameFLOW-Paradise project is moving towards 1993 ISO X.500Standard replication protocols and wants to standardise the protocol and procedure for managing the root naming context which will be based on 1993 X.500 Standard protocols. Such a protocol and procedure will be useful to private X.500 domains as well as to the InternetX.500 public domain. It is imperative that overall system performance is not degraded by this transition.
This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. |
|
| |
| RFC 2121 | Issues affecting MARS Cluster Size |
| |
| Authors: | G. Armitage. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2121 |
|
IP multicast over ATM currently uses the MARS model [1] to manage the use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope of any given MARS services is the MARS Cluster - typically the same as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are usually architected with unicast routing and forwarding issues dictating the sizes of individual LISes. However, as IP multicast is deployed as a service, the size of a LIS will only be as big as aMARS Cluster can be. This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. |
|
| |
| RFC 2122 | VEMMI URL Specification |
| |
| Authors: | D. Mavrakis, H. Layec, K. Kartmann. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2122 |
|
A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK] |
|
| |
| RFC 2123 | Traffic Flow Measurement: Experiences with NeTraMet |
| |
| Authors: | N. Brownlee. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2123 |
|
This memo records experiences in implementing and using the TrafficFlow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. |
|
| |
| RFC 2124 | Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 |
| |
| Authors: | P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2124 |
|
Light-weight Flow Admission Protocol, LFAP, allows an external FlowAdmission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch.
Specifically, this document specifies the protocol between the switchConnection Control Entity (CCE) and the external FAS. Using LFAP, aFlow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes. |
|
| |
| RFC 2125 | The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) |
| |
| Authors: | C. Richards, K. Smith. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2125 |
|
This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol[2]. This is done by defining the Bandwidth Allocation Protocol(BAP), as well as its associated control protocol, the BandwidthAllocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. |
|
| |
| RFC 2126 | ISO Transport Service on top of TCP (ITOT) |
| |
|
|
This document is a revision to STD35, RFC1006 written by Marshall T.Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006.
This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006.
The goal of this version is to minimise the number of changes toRFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users. |
|
| |
| RFC 2127 | ISDN Management Information Base using SMIv2 |
| |
| Authors: | G. Roeck, Ed.. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2127 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.
The current version of this document reflects changes made during the last call period and the IESG review. |
|
| |
| RFC 2128 | Dial Control Management Information Base using SMIv2 |
| |
| Authors: | G. Roeck, Ed.. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2128 |
|
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 demand access circuits, including ISDN.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. |
|
| |
| RFC 2129 | Toshiba's Flow Attribute Notification Protocol (FANP) Specification |
| |
| Authors: | K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2129 |
|
This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By usingFANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;
(1) soft-state cut-through path (Dedicated-VC) management(2) protocol between neighbor nodes instead of end-to-end(3) applicable to any connection oriented datalink platform |
|
| |
| RFC 2130 | The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 |
| |
| Authors: | C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. |
| Date: | April 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6055 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2130 |
|
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. |
|
| |
| RFC 2131 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP 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, 21], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 2132 | 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. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments [22].
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 2133 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | April 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2553 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2133 |
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5]. |
|
| |
| RFC 2134 | Articles of Incorporation of Internet Society |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2134 |
|
These are the articles of incorporation of the Internet Society.They are published for the information of the IETF community at the request of the poisson working group. |
|
| |
| RFC 2135 | Internet Society By-Laws |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2135 |
|
These are the by-laws of the Internet Society, as amended, as of June1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. |
|
| |
| RFC 2136 | Dynamic Updates in the Domain Name System (DNS UPDATE) |
| |
|
|
The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met. |
|
| |
| RFC 2137 | Secure Domain Name System Dynamic Update |
| |
|
|
Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. |
|
| |
| RFC 2138 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | April 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 2058 |
| Obsoleted by: | RFC 2865 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2138 |
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2139 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2140 | TCP Control Block Interdependence |
| |
|
|
This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI. |
|
| |
| RFC 2141 | URN Syntax |
| |
|
|
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. |
|
| |
| RFC 2142 | Mailbox Names for Common Services, Roles and Functions |
| |
| Authors: | D. Crocker. |
| Date: | May 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2142 |
|
This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK] |
|
| |
| RFC 2143 | Encapsulating IP with the Small Computer System Interface |
| |
| Authors: | B. Elliston. |
| Date: | May 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2143 |
|
This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2144 | The CAST-128 Encryption Algorithm |
| |
| Authors: | C. Adams. |
| Date: | May 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2144 |
|
There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (AppendixA), and a set of test vectors (Appendix B). |
|
| |
| RFC 2145 | Use and Interpretation of HTTP Version Numbers |
| |
| Authors: | J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. |
| Date: | May 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7230 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2145 |
|
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP. |
|
| |
| RFC 2146 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | May 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 1816 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2146 |
|
This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. Two documents are recognized as constituting documentation on the US government structure: FIPS 95-1 provides a standard recognized structure into which domain registrations for .GOV and FED.US can fit; and, the US Government Manual [3], a special publication of theFederal Register, provides official documentation of the government structure. The latter document may be subject to more timely updates than the former. Either document is suitable for determining which entities qualify for second-level domain registration within .GOV andFED.US.
As a side effect, this RFC reduces the number of .GOV and FED.US level registrations and reduces the workload on the registration authority. Previous versions of this document did not address theFED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on theInternet today. |
|
| |
| RFC 2147 | TCP and UDP over IPv6 Jumbograms |
| |
|
|
IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK] |
|
| |
| RFC 2148 | Deployment of the Internet White Pages Service |
| |
| Authors: | H. Alvestrand, P. Jurg. |
| Date: | September 1997 |
| Formats: | txt json html |
| Also: | BCP 0015 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2148 |
|
This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2149 | Multicast Server Architectures for MARS-based ATM multicasting |
| |
| Authors: | R. Talpade, M. Ammar. |
| Date: | May 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2149 |
|
A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on aMulticast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined inRFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used withRFC 2022 based MARS server and clients, without needing any change in their functionality. |
|
| |
| RFC 2150 | Humanities and Arts: Sharing Center Stage on the Internet |
| |
|
|
This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.
The purpose of this document is to provide members of the Arts andHumanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.
The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure. |
|
| |
| RFC 2151 | A Primer On Internet and TCP/IP Tools and Utilities |
| |
|
|
This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtainInternet and TCP/IP documents, and some resources that help users weave their way through the Internet. |
|
| |
| RFC 2152 | UTF-7 A Mail-Safe Transformation Format of Unicode |
| |
|
|
The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 2045 through 2049) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641,"Using Unicode with MIME". |
|
| |
| RFC 2153 | PPP Vendor Extensions |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines a general mechanism for proprietary vendor extensions. |
|
| |
| RFC 2154 | OSPF with Digital Signatures |
| |
| Authors: | S. Murphy, M. Badger, B. Wellington. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2154 |
|
This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described. |
|
| |
| RFC 2155 | Definitions of Managed Objects for APPN using SMIv2 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | June 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2455 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2155 |
|
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 monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] |
|
| |
| RFC 2156 | MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME |
| |
|
|
This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] |
|
| |
| RFC 2157 | Mapping between X.400 and RFC-822/MIME Message Bodies |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2157 |
|
This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK] |
|
| |
| RFC 2158 | X.400 Image Body Parts |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2158 |
|
This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK] |
|
| |
| RFC 2159 | A MIME Body Part for FAX |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2159 |
|
This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK] |
|
| |
| RFC 2160 | Carrying PostScript in X.400 and MIME |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2160 |
|
This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK] |
|
| |
| RFC 2161 | A MIME Body Part for ODA |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2161 |
|
This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2162 | MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail |
| |
|
|
This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol.The specifications are valid both within DECnet Phase IV andDECnet/OSI addressing and routing scheme.
The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.
This document obsoletes RFC 1405, which was a combined effort ofTERENA Working Group on Messaging, and the IETF X.400 Ops WorkingGroup. This update was prepared by IETF MIXER working group. |
|
| |
| RFC 2163 | Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) |
| |
|
|
This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed.
This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.
RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group. |
|
| |
| RFC 2164 | Use of an X.500/LDAP directory to support MIXER address mapping |
| |
|
|
This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK] |
|
| |
| RFC 2165 | Service Location Protocol |
| |
|
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. |
|
| |
| RFC 2166 | APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements |
| |
| Authors: | D. Bryant, P. Brittain. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2166 |
|
This document specifies
- a set of extensions to RFC 1795 designed to improve the scalability of DLSw- clarifications to RFC 1795 in the light of the implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSwRIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message. |
|
| |
| RFC 2167 | Referral Whois (RWhois) Protocol V1.5 |
| |
| Authors: | S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. |
| Date: | June 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 1714 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2167 |
|
This memo describes Version 1.5 of the client/server interaction ofRWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism. |
|
| |
| RFC 2168 | Resolution of Uniform Resource Identifiers using the Domain Name System |
| |
|
|
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2169 | A Trivial Convention for using HTTP in URN Resolution |
| |
|
|
This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2170 | Application REQuested IP over ATM (AREQUIPA) |
| |
| Authors: | W. Almesberger, J. Le Boudec, P. Oechslin. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2170 |
|
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
Given a mapping from service classes, as defined by INTSERV[6], toATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.
The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.
We discuss the implementation of Arequipa for hosts running IPv4 andIPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.
In particular we show how
- Arequipa can be implemented in IPv4 by slightly modifying the- Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache,- Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses.
Finally, we address safety and security implications. |
|
| |
| RFC 2171 | MAPOS - Multiple Access Protocol over SONET/SDH Version 1 |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2171 |
|
This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams overSONET/SDH. It focuses on the core protocol -- other documents listed in the bibliography may be referenced in conjunction with this document to provide support and services for protocols at higher layers. |
|
| |
| RFC 2172 | MAPOS Version 1 Assigned Numbers |
| |
| Authors: | M. Maruyama, K. Murakami. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2172 |
|
This document describes the protocol parameters used in the MultipleAccess Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. |
|
| |
| RFC 2173 | A MAPOS version 1 Extension - Node Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2173 |
|
This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address configuration of each node. Using NSP, a node retrieves its HDLC address from the switch to which it is connected. |
|
| |
| RFC 2174 | A MAPOS version 1 Extension - Switch-Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2174 |
|
This document describes a MAPOS version 1 extension, SSP (SwitchSwitch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-LevelData Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, aSONET switch provides the multiple access capability to end nodes.SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment. |
|
| |
| RFC 2175 | MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2175 |
|
This document describes the protocol MAPOS 16, Multiple AccessProtocol over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol datagrams over SONET/SDH. The primary difference with MAPOS version 1 is that it has 16 bit address field that offers significant wide address space. It first describes the major differences between MAPOS and MAPOS 16 briefly. Then, it explains the header format and its 16 bit address format. |
|
| |
| RFC 2176 | IPv4 over MAPOS Version 1 |
| |
|
|
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP). |
|
| |
| RFC 2177 | IMAP4 IDLE command |
| |
| Authors: | B. Leiba. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2177 |
|
This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK] |
|
| |
| RFC 2178 | 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. 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.
The differences between this memo and RFC 1583 are explained inAppendix G. All differences are backward-compatible in nature.Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2179 | Network Security For Trade Shows |
| |
| Authors: | A. Gwinn. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2179 |
|
This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. Generally, it has been observed that many system administrators and trade show coordinators tend to overlook the importance of system security at trade shows. In fact, systems at trade shows are at least as prone to attack as office-based platforms. Trade show systems should be treated as seriously as an office computer. A breach of security of a trade show system can render -- and has rendered -- an exhibitor's demonstrations inoperable -- sometimes for the entire event!
This document is not intended to replace the multitudes of comprehensive books on the subject of Internet security. Rather, its purpose is to provide a checklist-style collection of frequently overlooked, simple ways to minimize the chance of a costly attack.We encourage exhibitors to pay special attention to this document and share it with all associated representatives. |
|
| |
| RFC 2180 | IMAP4 Multi-Accessed Mailbox Practice |
| |
| Authors: | M. Gahrns. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2180 |
|
The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2181 | Clarifications to the DNS Specification |
| |
|
|
This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK] |
|
| |
| RFC 2182 | Selection and Operation of Secondary DNS Servers |
| |
| Authors: | R. Elz, R. Bush, S. Bradner, M. Patton. |
| Date: | July 1997 |
| Formats: | txt html json |
| Also: | BCP 0016 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2182 |
|
The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. |
|
| |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |
| |
|
|
This memo provides a mechanism whereby messages conforming to theMIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC2049] can convey presentational information. It specifies the"Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and[RFC 822]. The information presented herein supplements but does not replace that found in those documents.
This document is a revision to the Experimental protocol defined inRFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the FileTransfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values. |
|
| |
| RFC 2184 | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations |
| |
|
|
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK] |
|
| |
| RFC 2185 | Routing Aspects of IPv6 Transition |
| |
| Authors: | R. Callon, D. Haskin. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2185 |
|
This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document"Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document.
The proposals contained in this document are based on the work of theNgtrans working group. |
|
| |
| RFC 2186 | Internet Cache Protocol (ICP), version 2 |
| |
| Authors: | D. Wessels, K. Claffy. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2186 |
|
This document describes version 2 of the Internet Cache Protocol(ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object.
This document describes only the format and fields of ICP messages.A companion document (RFC2187) describes the application of ICP toWeb caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses ofICP for those trying to implement, deploy, and extend its use for their own purposes. |
|
| |
| RFC 2187 | Application of Internet Cache Protocol (ICP), version 2 |
| |
| Authors: | D. Wessels, K. Claffy. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2187 |
|
This document describes the application of ICPv2 (Internet CacheProtocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use.
ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior. |
|
| |
| RFC 2188 | AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 |
| |
| Authors: | M. Banan, M. Taylor, J. Cheng. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2188 |
|
This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The emphasis of ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind.
ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO protocol supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications).
ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way hand-shake and 3-way hand-shake based protocols.
Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of this document. But, identification (tagging) of the encoding mechanism in use (e.g., XDR,
BER, PER) is supported by ESRO protocol.
A variety of applications can use the ESRO protocol. Some early applications using ESRO include efficient short message submission and delivery, credit card authorization and white pages lookup. |
|
| |
| RFC 2189 | Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- |
| |
| Authors: | A. Ballardie. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2189 |
|
This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing.
CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1].
This document is progressing through the IDMR working group of theIETF. CBT related documents include [1, 5, 6]. For all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr. |
|
| |
| RFC 2190 | RTP Payload Format for H.263 Video Streams |
| |
| Authors: | C. Zhu. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2190 |
|
This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortestH.263 payload header (mode A) supports fragmentation at Group ofBlock (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. |
|
| |
| RFC 2191 | VENUS - Very Extensive Non-Unicast Service |
| |
| Authors: | G. Armitage. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2191 |
|
The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting over ATM, establishing and managing the use of ATM pt- mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the "Classical IP over ATM" model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. There are a number of different approaches. This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service"(VENUS), and shows how complex such a service would be. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts towards alternative solutions for establishingATM level multicast connections between LISes. |
|
| |
| RFC 2192 | IMAP URL Scheme |
| |
|
|
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server. |
|
| |
| RFC 2193 | IMAP4 Mailbox Referrals |
| |
| Authors: | M. Gahrns. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2193 |
|
Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK] |
|
| |
| RFC 2194 | Review of Roaming Implementations |
| |
| Authors: | B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2194 |
|
This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2195 | IMAP/POP AUTHorize Extension for Simple Challenge/Response |
| |
| Authors: | J. Klensin, R. Catoe, P. Krumviede. |
| Date: | September 1997 |
| Formats: | txt json html |
| Obsoletes: | RFC 2095 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2195 |
|
While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. |
|
| |
| RFC 2196 | Site Security Handbook |
| |
|
|
This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. |
|
| |
| RFC 2197 | SMTP Service Extension for Command Pipelining |
| |
|
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK] |
|
| |
| RFC 2198 | RTP Payload for Redundant Audio Data |
| |
| Authors: | C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. |
| Date: | September 1997 |
| Formats: | txt json html |
| Updated by: | RFC 6354 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2198 |
|
This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. |
|
| |
| RFC 2199 | Request for Comments Summary RFC Numbers 2100-2199 |
| |
| Authors: | A. Ramos. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2199 |
|
|
|
