The RFC Archive   RFC    « Jump to any RFC number directly

RFC Home	Full RFC Index	Recent RFCs	RFC Standards	Best Current Practice	RFC Errata	1 April RFC

Index: RFC 2401-2500

RFC 2401

Security Architecture for the Internet Protocol

Summary  Publication date: Nov 1998 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast.

RFC 2402

IP Authentication Header

Summary  Publication date: Nov 1998 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode).

RFC 2403

The Use of HMAC-MD5-96 within ESP and AH

Summary  Publication date: Nov 1998 This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the MD5 algorithm [RFC 1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

RFC 2404

The Use of HMAC-SHA-1-96 within ESP and AH

Summary  Publication date: Nov 1998 This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

RFC 2405	The ESP DES-CBC Cipher Algorithm With Explicit IV
	Summary  Publication date: Nov 1998 This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP).

RFC 2406

IP Encapsulating Security Payload (ESP)

Summary  Publication date: Nov 1998 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.

RFC 2407

The Internet IP Security Domain of Interpretation for ISAKMP

Summary  Publication date: Nov 1998 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a list of changes since the previous version of the IPSEC DOI, please see Section 7.

RFC 2408

Internet Security Association and Key Management Protocol (ISAKMP)

Summary  Publication date: Nov 1998 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment.

RFC 2409

The Internet Key Exchange (IKE)

Summary  Publication date: Nov 1998 ISAKMP ([MSST98]) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. Oakley ([Orm96]) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). SKEME ([SKEME]) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI.

RFC 2410

The NULL Encryption Algorithm and Its Use With IPsec

Summary  Publication date: Nov 1998 This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality. Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD].

RFC 2411

IP Security Document Roadmap

Summary  Publication date: Nov 1998 The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and Authentication Algorithm documents are described.

RFC 2412

The OAKLEY Key Determination Protocol

Summary  Publication date: Nov 1998 This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms.

RFC 2413

Dublin Core Metadata for Resource Discovery

Summary  Publication date: Sep 1998 The Dublin Core Metadata Workshop Series began in 1995 with an invitational workshop which brought together librarians, digital library researchers, content experts, and text-markup experts to promote better discovery standards for electronic resources. The Dublin Core is a 15-element set of descriptors that has emerged from this effort in interdisciplinary and international consensus building. This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements.

RFC 2414	Increasing TCP's Initial Window
	Summary  Publication date: Sep 1998 This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP.

RFC 2415

Simulation Studies of Increased Initial TCP Window Size

Summary  Publication date: Sep 1998 An increase in the permissible initial window size of a TCP connection, from one segment to three or four segments, has been under discussion in the tcp-impl working group. This document covers some simulation studies of the effects of increasing the initial window size of TCP. Both long-lived TCP connections (file transfers) and short-lived web-browsing style connections were modeled. The simulations were performed using the publicly available ns-2 simulator and our custom models and files are also available.

RFC 2416

When TCP Starts Up With Four Packets Into Only Three Buffers

Summary  Publication date: Sep 1998 This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).

RFC 2417

Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks

Summary  Publication date: Sep 1998 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 for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2418

IETF Working Group Guidelines and Procedures

Summary  Publication date: Sep 1998 The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors.

RFC 2419

The PPP DES Encryption Protocol, Version 2 (DESE-bis)

Summary  Publication date: Sep 1998 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.

RFC 2420

The PPP Triple-DES Encryption Protocol (3DESE)

Summary  Publication date: Sep 1998 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.

RFC 2421

Voice Profile for Internet Mail - version 2

Summary  Publication date: Sep 1998 A class of special-purpose computers has evolved to provide voice messaging services. These machines generally interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines. The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice messaging networking protocol. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document. This profile is based on earlier work in the Audio Message Interchange Specification (AMIS) group that defined a voice messaging protocol based on X.400 technology. This profile is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate intranets. This second version of VPIM is based on implementation experience and obsoletes RFC 1911 which describes version 1 of the profile.

RFC 2422	Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
	Summary  Publication date: Sep 1998 This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. This document refines an earlier sub-type registration in RFC 1911.

RFC 2423	VPIM Voice Message MIME Sub-type Registration
	Summary  Publication date: Sep 1998 This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). A full description of usage can be found in the VPIM v2 specification [VPIM2]. This document revises an earlier sub-type registration in RFC 1911 [VPIM1].

RFC 2424	Content Duration MIME Header Definition
	Summary  Publication date: Sep 1998 This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). The length of time is represented in seconds without any units indication.

RFC 2425

A MIME Content-Type for Directory Information

Summary  Publication date: Sep 1998 This document defines a MIME Content-Type for holding directory information. The definition is independent of any particular directory service or protocol. The text/directory Content-Type is defined for holding a variety of directory information, for example, name, or email address, or logo. The text/directory Content-Type can also be used as the root body part in a multipart/related Content- Type for handling more complicated situations, especially those in which non-textual information that already has a natural MIME representation, for example, a photograph or sound, is to be represented. The text/directory Content-Type defines a general framework and format for holding directory information in a simple "type:value" form. We refer to "type" in this context meaning a property or attribute with which the value is associated. Mechanisms are defined to specify alternate languages, encodings and other meta-information. This document also defines the procedure by which particular formats, called profiles, for carrying application-specific information within a text/directory Content-Type can be defined and registered, and the conventions such formats must follow. It is expected that other documents will be produced that define such formats for various applications (e.g., white pages).

RFC 2426

vCard MIME Directory Profile

Summary  Publication date: Sep 1998 This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document.

RFC 2427

Multiprotocol Interconnect over Frame Relay

Summary  Publication date: Sep 1998 This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.

RFC 2428

FTP Extensions for IPv6 and NATs

Summary  Publication date: Sep 1998 The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.

RFC 2429

RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)

Summary  Publication date: Oct 1998 This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 [3], and is recommended for this use by new implementations. This format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 shall use the format described in this document.

RFC 2430

A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)

Summary  Publication date: Oct 1998 This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). Providing differentiated services in ISPs is a challenge because the scaling problems presented by the sheer number of flows present in large ISPs makes the cost of maintaining per-flow state unacceptable. Coupled with this, large ISPs need the ability to perform traffic engineering by directing aggregated flows of traffic along specific paths. PASTE addresses these issues by using Multiprotocol Label Switching (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to create a scalable traffic management architecture that supports differentiated services. This document assumes that the reader has at least some familiarity with both of these technologies.

RFC 2431	RTP Payload Format for BT.656 Video Encoding
	Summary  Publication date: Oct 1998 This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.

RFC 2432

Terminology for IP Multicast Benchmarking

Summary  Publication date: Oct 1998 The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.

RFC 2433

Microsoft PPP CHAP Extensions

Summary  Publication date: Oct 1998 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which extends the user authentication functionality provided on Windows networks to remote workstations. MS-CHAP is closely derived from the PPP Challenge Handshake Authentication Protocol described in RFC 1994 [2], which the reader should have at hand. The algorithms used in the generation of various MS-CHAP protocol fields are described in an appendix.

RFC 2434

Guidelines for Writing an IANA Considerations Section in RFCs

Summary  Publication date: Oct 1998 Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.

RFC 2435

RTP Payload Format for JPEG-compressed Video

Summary  Publication date: Oct 1998 This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).

RFC 2436

Collaboration between ISOC/IETF and ITU-T

Summary  Publication date: Oct 1998 This document describes the collaboration process between the ITU-T and ISOC/IETF. The process was documented by ITU-T at its TSAG (Telecommunication Standardization Advisory Group) meeting in September 1998. All participants of this meeting (including Study Group chairmen and the ISOC Vice President for Standards) assisted in the creation of this document. Subsequently, it was sent to all ITU-T Study Groups and ISOC/IETF to ensure that everyone was aware of the process. Feedback is requested by the next meeting of TSAG in April 1999. This document is identical to the document produced by TSAG.

RFC 2437

PKCS #1: RSA Cryptography Specifications Version 2.0

Summary  Publication date: Oct 1998 This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm [18], covering the following aspects: -cryptographic primitives -encryption schemes -signature schemes with appendix -ASN.1 syntax for representing keys and for identifying the schemes The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. It is expected that application standards based on these specifications may include additional constraints. The recommendations are intended to be compatible with draft standards currently being developed by the ANSI X9F1 [1] and IEEE P1363 working groups [14]. This document supersedes PKCS #1 version 1.5 [20]. Editor's note. It is expected that subsequent versions of PKCS #1 may cover other aspects of the RSA algorithm such as key size, key generation, key validation, and signature schemes with message recovery.

RFC 2438

Advancement of MIB specifications on the IETF Standards Track

Summary  Publication date: Oct 1998 The Internet Standards Process [1] requires that all IETF Standards Track specifications must have "multiple, independent, and interoperable implementations" before they can be advanced beyond Proposed Standard status. This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process.

RFC 2439

BGP Route Flap Damping

Summary  Publication date: Nov 1998 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is "route flap". The techniques described here are now widely deployed and are commonly referred to as "route flap damping".

RFC 2440

OpenPGP Message Format

Summary  Publication date: Nov 1998 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP.

RFC 2441	Working with Jon, Tribute delivered at UCLA, October 30, 1998
	Summary  Publication date: Nov 1998 A Tribute to Jon Postel.

RFC 2442

The Batch SMTP Media Type

Summary  Publication date: Nov 1998 This document defines a MIME content type suitable for tunneling an ESMTP [RFC 821, RFC 1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g., [RFC 1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such as NOTARY [RFC 1891] over unextended SMTP transport infrastructure. Enabling the transfer of multiple separate messages in a single transactional unit.

RFC 2443	A Distributed MARS Service Using SCSP
	Summary  Publication date: Nov 1998 This document describes a method for distributing a MARS service within a LIS[1]. This method uses the Server Cache Synchronization Protocol (SCSP)[2] to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG).

RFC 2444	The One-Time-Password SASL Mechanism
	Summary  Publication date: Oct 1998 OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into many application protocols.

RFC 2445

Internet Calendaring and Scheduling Core Object Specification (iCalendar)

Summary  Publication date: Nov 1998 There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below.

RFC 2446

iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries

Summary  Publication date: Nov 1998 This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify interoperable methods of communications between systems that use this protocol. The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol (iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.

RFC 2447

iCalendar Message-Based Interoperability Protocol (iMIP)

Summary  Publication date: Nov 1998 This document, [iMIP], specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model [iCAL] are composed using constructs from [RFC 822], [RFC 2045], [RFC 2046], [RFC 2047], [RFC 2048] and [RFC 2049]. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.

RFC 2448	AT&T's Error Resilient Video Transmission Technique
	Summary  Publication date: Nov 1998 This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. The described techniques can be used over packet networks without packet prioritization. These techniques are related to AT&T/Lucent patents [1, 2].

RFC 2449

POP3 Extension Mechanism

Summary  Publication date: Nov 1998 The Post Office Protocol version 3 [POP3] is very widely used. However, while it includes some optional commands (and some useful protocol extensions have been published), it lacks a mechanism for advertising support for these extensions or for behavior variations. Currently these optional features and extensions can only be detected by probing, if at all. This is at best inefficient, and possibly worse. As a result, some clients have manual configuration options for POP3 server capabilities. Because one of the most important characteristics of POP3 is its simplicity, it is desirable that extensions be few in number (see section 7). However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In addition, a means for discovering server behavior is needed. This memo updates RFC 1939 [POP3] to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. Included is an initial set of currently deployed capabilities which vary between server implementations, and several new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION). This document also extends POP3 error messages so that machine parsable codes can be provided to the client. An initial set of response codes is included. In addition, an [ABNF] specification of POP3 commands and responses is defined.

RFC 2450

Proposed TLA and NLA Assignment Rule

Summary  Publication date: Dec 1998 This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries.

RFC 2451	The ESP CBC-Mode Cipher Algorithms
	Summary  Publication date: Nov 1998 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms.

RFC 2452

IP Version 6 Management Information Base for the Transmission Control Protocol

Summary  Publication date: Dec 1998 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie TCP, and only the TCP connection information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.

RFC 2453	RIP Version 2
	Summary  Publication date: Nov 1998 This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2 [2]. An additional document will define cryptographic security improvements for RIP-2 [3].

RFC 2454

IP Version 6 Management Information Base for the User Datagram Protocol

Summary  Publication date: Dec 1998 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.

RFC 2455	Definitions of Managed Objects for APPN
	Summary  Publication date: Nov 1998 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 2456

Definitions of Managed Objects for APPN TRAPS

Summary  Publication date: Nov 1998 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 receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture.

RFC 2457

Definitions of Managed Objects for Extended Border Node

Summary  Publication date: Nov 1998 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 Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture.

RFC 2458

Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations

Summary  Publication date: Nov 1998 This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.

RFC 2459

Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Summary  Publication date: Jan 1999 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices.

RFC 2460	Internet Protocol, Version 6 (IPv6) Specification
	Summary  Publication date: Dec 1998 This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.

RFC 2461	Neighbor Discovery for IP Version 6 (IPv6)
	Summary  Publication date: Dec 1998 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.

RFC 2462

IPv6 Stateless Address Autoconfiguration

Summary  Publication date: Dec 1998 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.

RFC 2463	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
	Summary  Publication date: Dec 1998 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6).

RFC 2464

Transmission of IPv6 Packets over Ethernet Networks

Summary  Publication date: Dec 1998 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. This document replaces RFC 1972, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", which will become historic.

RFC 2465

Management Information Base for IP Version 6: Textual Conventions and General Group

Summary  Publication date: Dec 1998 This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2466

Management Information Base for IP Version 6: ICMPv6 Group

Summary  Publication date: Dec 1998 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2467

Transmission of IPv6 Packets over FDDI Networks

Summary  Publication date: Dec 1998 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document replaces RFC 2019, "Transmission of IPv6 Packets Over FDDI", which will become historic.

RFC 2468	I REMEMBER IANA
	Summary  Publication date: Oct 1998 A Tribute to Jon Postel.

RFC 2469

A Caution On The Canonical Ordering Of Link-Layer Addresses

Summary  Publication date: Dec 1998 Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.

RFC 2470

Transmission of IPv6 Packets over Token Ring Networks

Summary  Publication date: Dec 1998 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Implementors should be careful to note that Token Ring adaptors assume addresses are in non-canonical rather than canonical format, requiring that special care be taken to insure that addresses are processed correctly. See [CANON] for more details.

RFC 2471

IPv6 Testing Address Allocation

Summary  Publication date: Dec 1998 This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. The address format for the IPv6 test address is consistent with the "Aggregatable Global Unicast Address Allocation" [AGGR] and "TLA and NLA Assignment Rules" [TLAASN]. This document is intended to replace RFC 1897 "IPv6 Testing Address Allocation", January 1996. RFC 1897 will become historic. The addresses described in this document are consistent with the IPv6 Addressing Architecture [ARCH]. They may be assigned to nodes manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for IPv6 [DHCPv6].

RFC 2472

IP Version 6 over PPP

Summary  Publication date: Dec 1998 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.

RFC 2473	Generic Packet Tunneling in IPv6 Specification
	Summary  Publication date: Dec 1998 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.

RFC 2474

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Summary  Publication date: Dec 1998 Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of: - setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), - using those bits to determine how packets are forwarded by the nodes inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity. This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.

RFC 2475

An Architecture for Differentiated Service

Summary  Publication date: Dec 1998 This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.

RFC 2476

Message Submission

Summary  Publication date: Dec 1998 SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA]. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA). Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality. Separating messages into submissions and transfers allows developers and network administrators to more easily: * Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail * Implement authenticated submission, including off-site submission by authorized users such as travelers * Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission * Detect configuration problems with a site's mail clients * Provide a basis for adding enhanced submission services in the future This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.

RFC 2477	Criteria for Evaluating Roaming Protocols
	Summary  Publication date: Jan 1999 This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one.

RFC 2478

The Simple and Protected GSS-API Negotiation Mechanism

Summary  Publication date: Dec 1998 This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism.

RFC 2479

Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)

Summary  Publication date: Dec 1998 The IDUP-GSS-API extends the GSS-API [RFC 2078] for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. Thus, it is suitable for applications such as secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. The protection offered by IDUP includes services such as data origin authentication with data integrity, data confidentiality with data integrity, and support for non-repudiation services. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed ("unprotected") only days or years later. Throughout the remainder of this document, the "unit" of data described in the above paragraph will be referred to as an IDU (Independent Data Unit). The IDU can be of any size (the application may, if it wishes, split the IDU into pieces and have the protection computed a piece at a time, but the resulting protection token applies to the entire IDU). However, the primary characteristic of an IDU is that it represents a stand-alone unit of data whose protection is entirely independent of any other unit of data. If an application protects several IDUs and sends them all to a single receiver, the IDUs may be unprotected by that receiver in any order over any time span; no logical connection of any kind is implied by the protection process itself. As with RFC 2078, this IDUP-GSS-API definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source- level portability of applications to different environments. This specification defines IDUP-GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications.

RFC 2480	Gateways and MIME Security Multiparts
	Summary  Publication date: Jan 1999 This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. A set of requirements for gateway behavior are defined which provide facilities necessary to properly accomodate the transfer of security multiparts through gateways.

RFC 2481

A Proposal to add Explicit Congestion Notification (ECN) to IP

Summary  Publication date: Jan 1999 This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process.

RFC 2482

Language Tagging in Unicode Plain Text

Summary  Publication date: Jan 1999 This document proposed a mechanism for language tagging in [UNICODE] plain text. A set of special-use tag characters on Plane 14 of [ISO10646] (accessible through UTF-8, UTF-16, and UCS-4 encoding forms) are proposed for encoding to enable the spelling out of ASCII-based string tags using characters which can be strictly separated from ordinary text content characters in ISO10646 (or UNICODE). One tag identification character and one cancel tag character are also proposed. In particular, a language tag identification character is proposed to identify a language tag string specifically; the language tag itself makes use of [RFC 1766] language tag strings spelled out using the Plane 14 tag characters. Provision of a specific, low-overhead mechanism for embedding language tags in plain text is aimed at meeting the need of Internet Protocols such as ACAP, which require a standard mechanism for marking language in UTF-8 strings. The tagging mechanism as well the characters proposed in this document have been approved by the Unicode Consortium for inclusion in The Unicode Standard. However, implementation of this decision awaits formal acceptance by ISO JTC1/SC2/WG2, the working group responsible for ISO10646. Potential implementers should be aware that until this formal acceptance occurs, any usage of the characters proposed herein is strictly experimental and not sanctioned for standardized character data interchange.

RFC 2483

URI Resolution Services Necessary for URN Resolution

Summary  Publication date: Jan 1999 Retrieving the resource identified by a Uniform Resource Identifier (URI) [1] is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them. This memo specifies an initial set of these operations that can be used to describe the interactions provided by a given access service. It also suggests guidelines that should be adhered to when those operations are encoded in a protocol.

RFC 2484

PPP LCP Internationalization Configuration Option

Summary  Publication date: Jan 1999 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5].

RFC 2485	DHCP Option for The Open Group's User Authentication Protocol
	Summary  Publication date: Jan 1999 This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard [2].

RFC 2486

The Network Access Identifier

Summary  Publication date: Jan 1999 In order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. It is expected that this will be of interest for support of roaming as well as tunneling. "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 where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support.

RFC 2487	SMTP Service Extension for Secure SMTP over TLS
	Summary  Publication date: Jan 1999 This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.

RFC 2488

Enhancing TCP Over Satellite Channels using Standard Mechanisms

Summary  Publication date: Jan 1999 The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards).

RFC 2489

Procedure for Defining New DHCP Options

Summary  Publication date: Jan 1999 The Dynamic Host Configuration Protocol (DHCP) 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." New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options.

RFC 2490

A Simulation Model for IP Multicast with RSVP

Summary  Publication date: Jan 1999 This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting.

RFC 2491

IPv6 over Non-Broadcast Multiple Access (NBMA) networks

Summary  Publication date: Jan 1999 This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described. Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor Discovery protocol operation within Logical Links, and inter-router NHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported.

RFC 2492

IPv6 over ATM Networks

Summary  Publication date: Jan 1999 This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.

RFC 2493	Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
	Summary  Publication date: Jan 1999 This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals.

RFC 2494

Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type

Summary  Publication date: Jan 1999 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 objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]), DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2495

Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types

Summary  Publication date: Jan 1999 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 objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3 (RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2496

Definitions of Managed Object for the DS3/E3 Interface Type

Summary  Publication date: Jan 1999 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 objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC 2495 [17]), and the work in progress SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2497

Transmission of IPv6 Packets over ARCnet Networks

Summary  Publication date: Jan 1999 This memo specifies a frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an ARCnet.

RFC 2498

IPPM Metrics for Measuring Connectivity

Summary  Publication date: Jan 1999 Connectivity is the basic stuff from which the Internet is made. Therefore, metrics determining whether pairs of hosts (IP addresses) can reach each other must form the base of a measurement suite. We define several such metrics, some of which serve mainly as building blocks for the others. This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. The reader is assumed to be familiar with that document.

RFC 2499	Request for Comments Summary
	Summary  Publication date: Jul 1999 This RFC is a slightly annotated list of the 100 RFCs from RFC 2400 through RFCs 2499. This is a status report on these RFCs.

RFC 2500	Internet Official Protocol Standards
	Summary  Publication date: Jun 1999 This memo summarizes the status of Internet protocols and specifications. It is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet stnadards are set. This memo is prepared by the RFC Editor for the IESG and IAB.

RFC-ARCHIVE.ORG

© all RFCs, STDs, BCPs: The IETF Trust
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen