|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2101 |
 IPv4 Address Behaviour Today
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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 of HMAC depends on the properties of the underlying hash function. |
| RFC 2105 |
Cisco Systems' Tag Switching Architecture Overview
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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 In User 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
|
|
Summary Publication date: Feb 1997 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 100 Mb/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
|
|
Summary Publication date: Feb 1997 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. (See the HISTORICAL section.) |
| RFC 2110 |
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
|
|
Summary Publication date: Mar 1997 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 using HTML 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
|
|
Summary Publication date: Mar 1997 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
|
|
Summary Publication date: Mar 1997 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
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Feb 1997 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
|
|
Summary Publication date: Sep 1997 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. |
| RFC 2116 |
X.500 Implementations Catalog-96
|
|
Summary Publication date: Apr 1997 This document is a revision to [RFC 1632]: A Revised Catalog of Available 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 of X.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
|
|
Summary Publication date: Jun 1997 This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. |
| RFC 2118 |
Microsoft Point-To-Point Compression (MPPC) Protocol
|
|
Summary Publication date: Mar 1997 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 Point Compression 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
|
|
Summary Publication date: Mar 1997 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. |
| RFC 2120 |
Managing the X.500 Root Naming Context
|
|
Summary Publication date: Mar 1997 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 and 1993 X.500 Standard. The NameFLOW-Paradise project is moving towards 1993 ISO X.500 Standard 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 Internet X.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
|
|
Summary Publication date: Mar 1997 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 a MARS 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
|
|
Summary Publication date: Mar 1997 A new URL scheme, "vemmi" is defined. It allows VEMMI client software and VEMMI terminals to connect to multimedia interactive services compliant to the VEMMI standard (Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services), sometimes abbreviated as "VErsatile MultiMedia Interface". 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) [2] and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382 [3], obsoleted by ETS 300 709 [1]). VEMMI could be described as an on-line multimedia protocol describing both the man-machine interface and the client/server exchange protocol. VEMMI operates usually on a single continuous session between a client and a host and supports an object-oriented, event- driven, client/server oriented and platform independent multimedia interface. The well-known tcp port number 575 has been assigned by IANA to the VEMMI protocol [13]. |
| RFC 2123 |
Traffic Flow Measurement: Experiences with NeTraMet
|
|
Summary Publication date: Mar 1997 This memo records experiences in implementing and using the Traffic Flow 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
|
|
Summary Publication date: Mar 1997 Light-weight Flow Admission Protocol, LFAP, allows an external Flow Admission 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 switch Connection Control Entity (CCE) and the external FAS. Using LFAP, a Flow 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)
|
|
Summary Publication date: Mar 1997 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 Bandwidth Allocation 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)
|
|
Summary Publication date: Mar 1997 This document is a revision to STD35, RFC 1006 written by Marshall T. Rose and Dwight E. Cass. Since the release of RFC 1006 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 RFC 1006. 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 RFC 1006. The goal of this version is to minimise the number of changes to RFC 1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC 1006 users. |
| RFC 2127 |
ISDN Management Information Base using SMIv2
|
|
Summary Publication date: Mar 1997 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 the Internet 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
|
|
Summary Publication date: Mar 1997 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 the Internet 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
|
|
Summary Publication date: Apr 1997 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 using FANP, 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
|
|
Summary Publication date: Apr 1997 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 the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. |
| RFC 2131 |
Dynamic Host Configuration Protocol
|
|
Summary Publication date: Mar 1997 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 of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]. |
| RFC 2132 |
DHCP Options and BOOTP Vendor Extensions
|
|
Summary Publication date: Mar 1997 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 the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. |
| RFC 2133 |
Basic Socket Interface Extensions for IPv6
|
|
Summary Publication date: Apr 1997 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 support IPv6 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 by TCP 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
|
|
Summary Publication date: Apr 1997 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
|
|
Summary Publication date: Apr 1997 These are the by-laws of the Internet Society, as amended, as of June 1996. 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)
|
|
Summary Publication date: Apr 1997 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 an RRset, 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
|
|
Summary Publication date: Apr 1997 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services [RFC 2065]. DNS Dynamic Update operations have also been defined [RFC 2136], 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)
|
|
Summary Publication date: Apr 1997 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. |
| RFC 2139 |
RADIUS Accounting
|
|
Summary Publication date: Apr 1997 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. |
| RFC 2140 |
TCP Control Block Interdependence
|
|
Summary Publication date: Apr 1997 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
|
|
Summary Publication date: May 1997 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
|
|
Summary Publication date: May 1997 This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. Mailbox names are provided for both operations and business functions. Additional mailbox names and aliases are not prohibited, but organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name for which the associated function exists within the organization. |
| RFC 2143 |
Encapsulating IP with the Small Computer System Interface
|
|
Summary Publication date: May 1997 As the capacity of local area networks increases to meet the demands of high volume application data, there is a class of network intensive problems which may be applied to small clusters of workstations with high bandwidth interconnection. A general observation of networks is that the bit rate of the data path typically decreases as the distance between hosts increases. It is common to see regional networks connected at a rate of 64Kbps and office networks connected at 100Mbps, but the inverse is far less common. The same is true of peripheral and memory interconnection. Memory close to a CPU's core may run at speeds equivalent to a gigabit network. More importantly, devices such as disks may connect a number of metres away from its host at speeds well in excess of current local area network capacity. This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. Despite the limitation in the furthest distance between hosts, SCSI permits close clusters of workstations to communicate between each other at speeds approaching 360 megabits per second. The proposed introduction of newer SCSI implementations such as serial SCSI will bring much faster communication at greater distances. |
| RFC 2144 |
The CAST-128 Encryption Algorithm
|
|
Summary Publication date: May 1997 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 (Appendix A), and a set of test vectors (Appendix B). |
| RFC 2145 |
Use and Interpretation of HTTP Version Numbers
|
|
Summary Publication date: May 1997 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 existing HTTP/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. Government Internet Domain Names
|
|
Summary Publication date: May 1997 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 the Federal 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 and FED.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 the FED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on the Internet today. |
| RFC 2147 |
TCP and UDP over IPv6 Jumbograms
|
|
Summary Publication date: May 1997 IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option [Deering95]. 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. |
| RFC 2148 |
Deployment of the Internet White Pages Service
|
|
Summary Publication date: Sep 1997 The Internet is used for information exchange and communication between its users. It can only be effective as such if users are able to find each other's addresses. Therefore the Internet benefits from an adequate White Pages Service, i.e., a directory service offering (Internet) address information related to people and organizations. This document describes the way in which the Internet White Pages Service (from now on abbreviated as IWPS) is best exploited using today's experience, today's protocols, today's products and today's procedures. |
| RFC 2149 |
Multicast Server Architectures for MARS-based ATM multicasting
|
|
Summary Publication date: May 1997 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 a Multicast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. |
| RFC 2150 |
Humanities and Arts: Sharing Center Stage on the Internet
|
|
Summary Publication date: Oct 1997 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 and Humanities 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
|
|
Summary Publication date: Jun 1997 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 obtain Internet 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
|
|
Summary Publication date: May 1997 The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to as Unicode) 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) extends Internet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither defines Unicode 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
|
|
Summary Publication date: May 1997 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 of Network 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
|
|
Summary Publication date: Jun 1997 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
|
|
Summary Publication date: Jun 1997 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. |
| RFC 2156 |
MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
|
|
Summary Publication date: Jan 1998 This RFC describes MIXER (Mime Internet X.400 Enhanced Relay), a Mapping between X.400 and RFC 822/MIME. |
| RFC 2157 |
Mapping between X.400 and RFC-822/MIME Message Bodies
|
|
Summary Publication date: Jan 1998 This document is a companion to [MIXER], which defines the principles and translation of headers for interworking between MIME-based RFC- 822 mail and X.400 mail. 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. |
| RFC 2158 |
X.400 Image Body Parts
|
|
Summary Publication date: Jan 1998 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. It also documents the OIDs assigned to these data formats as FTAM body parts, which allow the MIME types to be converted to FTAM body parts; this will probably be more useful than the new body parts defined here. |
| RFC 2159 |
A MIME Body Part for FAX
|
|
Summary Publication date: Jan 1998 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. NOTE: At the moment, this format does not seem appropriate for a "general purpose image format for the Internet", if such a beast can exist. It exists only to carry information that is already in G3 Fax format, and may be usefully converted to other formats when used in specific contexts. |
| RFC 2160 |
Carrying PostScript in X.400 and MIME
|
|
Summary Publication date: Jan 1998 This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. It uses the notational conventions of [BODYMAP], and the conversion is further described in [MIXER]. Two ways of carrying PostScript in X.400 are described. One is using the FTAM Body Part, and one uses the Extended Body Part originally described in RFC 1494. The FTAM method is recommended. |
| RFC 2161 |
A MIME Body Part for ODA
|
|
Summary Publication date: Jan 1998 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. |
| RFC 2162 |
MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail
|
|
Summary Publication date: Jan 1998 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 and DECnet/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 RFC 822 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 of TERENA Working Group on Messaging, and the IETF X.400 Ops Working Group. This update was prepared by IETF MIXER working group. |
| RFC 2163 |
Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)
|
|
Summary Publication date: Jan 1998 This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC 822 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 local DNS 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 the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo obsoletes RFC 1664. It includes the changes introduced by MIXER specification with respect to RFC 1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC 1664 specification is mantained, too. RFC 1664 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
|
|
Summary Publication date: Jan 1998 MIXER (RFC 2156) defines an algorithm for use of a set of global mapping between X.400 and RFC 822 addresses [4]. This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. Mechanisms for representing OR Address and Domain hierarchies within the DIT are defined in [5, 2]. These techniques are used to define two independent subtrees in the DIT, which contain the mapping information. |
| RFC 2165 |
Service Location Protocol
|
|
Summary Publication date: Jun 1997 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
|
|
Summary Publication date: Jun 1997 This document defines v2.0 of Data Link Switching (DLSw) in the form of a set of enhancements to RFC 1795. These enhancements are designed to be fully backward compatible with existing RFC 1795 implementations. As a compatible set of enhancements to RFC 1795, this document does not replace or supersede RFC 1795. The bulk of these enhancements address scalability issues in DLSw v1.0. Reason codes have also been added to the HALT_DL and HALT_DL_NOACK SSP messages in order to improve the diagnostic information available. Finally, the appendix to this document lists a number of clarifications to RFC 1795 where the implementation experience to- date has shown that the original RFC was ambiguous or unclear. These clarifications should be read alongside RFC 1795 to obtain a full specification of the base v1.0 DLSw standard. |
| RFC 2167 |
Referral Whois (RWhois) Protocol V1.5
|
|
Summary Publication date: Jun 1997 This memo describes Version 1.5 of the client/server interaction of RWhois. 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
|
|
Summary Publication date: Jun 1997 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). The requirements document for URN resolution systems[15] 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. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR, the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. |
| RFC 2169 |
A Trivial Convention for using HTTP in URN Resolution
|
|
Summary Publication date: Jun 1997 The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver. 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. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated resolution protocols are developed later. |
| RFC 2170 |
Application REQuested IP over ATM (AREQUIPA)
|
|
Summary Publication date: Jul 1997 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], to ATM 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 and IPv6. 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
|
|
Summary Publication date: Jun 1997 This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams over SONET/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
|
|
Summary Publication date: Jun 1997 This document describes the protocol parameters used in the Multiple Access 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
|
|
Summary Publication date: Jun 1997 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
|
|
Summary Publication date: Jun 1997 This document describes a MAPOS version 1 extension, SSP (Switch Switch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, a SONET 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
|
|
Summary Publication date: Jun 1997 This document describes the protocol MAPOS 16, Multiple Access Protocol 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
|
|
Summary Publication date: Jun 1997 This document describes a protocol for transmission of the Internet Protocol 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
|
|
Summary Publication date: Jun 1997 The Internet Message Access Protocol [IMAP4] requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It's often more desirable to have the server transmit updates to the client in real time. This allows a user to see new mail immediately. It also helps some real-time applications based on IMAP, which might otherwise need to poll extremely often (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can't expect this behaviour and must poll.) 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. |
| RFC 2178 |
OSPF Version 2
|
|
Summary Publication date: Jul 1997 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 in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFC 1583 will interoperate. |
| RFC 2179 |
Network Security For Trade Shows
|
|
Summary Publication date: Jul 1997 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
|
|
Summary Publication date: Jul 1997 IMAP4[RFC 2060] is rich client/server protocol that allows a client to access and manipulate electronic mail messages on a server. Within the protocol framework, it is possible to have differing results for particular client/server interactions. If a protocol does not allow for this, it is often unduly restrictive. For example, when multiple clients are accessing a mailbox and one attempts to delete the mailbox, an IMAP4 server may choose to implement a solution based upon server architectural constraints or individual preference. With this flexibility comes greater client responsibility. It is not sufficient for a client to be written based upon the behavior of a particular IMAP server. Rather the client must be based upon the behavior allowed by the protocol. By documenting common IMAP4 server practice for the case of simultaneous client access to a mailbox, we hope to ensure the widest amount of inter-operation between IMAP4 clients and servers. 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. [RFC 2060] must always be consulted to determine IMAP4 compliance, especially for server behavior not described within this document. |
| RFC 2181 |
Clarifications to the DNS Specification
|
|
Summary Publication date: Jul 1997 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. Eight separate issues are considered: + IP packet header address usage from multi-homed servers, + TTLs in sets of records with the same name, class, and type, + correct handling of zone cuts, + three minor issues concerning SOA records and their use, + the precise definition of the Time to Live (TTL) + Use of the TC (truncated) header bit + the issue of what is an authoritative, or canonical, name, + and the issue of what makes a valid DNS label. The first six of these are areas where the correct behaviour has been somewhat unclear, we seek to rectify that. The other two are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications. |
| RFC 2182 |
Selection and Operation of Secondary DNS Servers
|
|
Summary Publication date: Jul 1997 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
|
|
Summary Publication date: Aug 1997 This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] 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 in RFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the File Transfer 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
|
|
Summary Publication date: Aug 1997 This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide (1) a means to specify parameter values in character sets other than US-ASCII, (2) to specify the language to be used should the value be displayed, and (3) a continuation mechanism for long parameter values to avoid problems with header line wrapping. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. |
| RFC 2185 |
Routing Aspects of IPv6 Transition
|
|
Summary Publication date: Sep 1997 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 the Ngtrans working group. |
| RFC 2186 |
Internet Cache Protocol (ICP), version 2
|
|
Summary Publication date: Sep 1997 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 (RFC 2187) describes the application of ICP to Web caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use for their own purposes. |
| RFC 2187 |
Application of Internet Cache Protocol (ICP), version 2
|
|
Summary Publication date: Sep 1997 This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC 2186) 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 (RFC 2186) 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
|
|
Summary Publication date: Sep 1997 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 --
|
|
Summary Publication date: Sep 1997 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 the IETF. 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
|
|
Summary Publication date: Sep 1997 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 shortest H.263 payload header (mode A) supports fragmentation at Group of Block (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
|
|
Summary Publication date: Sep 1997 The MARS model (RFC 2022) 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 establishing ATM level multicast connections between LISes. |
| RFC 2192 |
IMAP URL Scheme
|
|
Summary Publication date: Sep 1997 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 an IMAP server. |
| RFC 2193 |
IMAP4 Mailbox Referrals
|
|
Summary Publication date: Sep 1997 When dealing with large amounts of users, messages and geographically dispersed IMAP4 [RFC 2060] servers, it is often desirable to distribute messages amongst different servers within an organization. For example an administrator may choose to store user's personal mailboxes on a local IMAP4 server, while storing shared mailboxes remotely on another server. This type of configuration is common when it is uneconomical to store all data centrally due to limited bandwidth or disk resources. Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. A referral mechanism can provide efficiencies over the alternative "proxy method", in which the local IMAP4 server contacts the remote server on behalf of the client, and then transfers the data from the remote server to itself, and then on to the client. The referral mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server. |
| RFC 2194 |
Review of Roaming Implementations
|
|
Summary Publication date: Sep 1997 This document reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. |
| RFC 2195 |
IMAP/POP AUTHorize Extension for Simple Challenge/Response
|
|
Summary Publication date: Sep 1997 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
|
|
Summary Publication date: Sep 1997 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
|
|
Summary Publication date: Sep 1997 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. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. The present document is an updated version of RFC 1854 [3]. Only textual and editorial changes have been made; the protocol has not changed in any way. |
| RFC 2198 |
RTP Payload for Redundant Audio Data
|
|
Summary Publication date: Sep 1997 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
|
|
Summary Publication date: Jan 1998 This RFC is a slightly annotated list of the 100 RFCs from RFC 2100 through RFCs 2199. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. |
| RFC 2200 |
Internet Official Protocol Standards
|
|
Summary Publication date: Jun 1997 This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. Distribution of this memo is unlimited. |
