| |
| RFC 2400 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK] |
|
| |
| RFC 2401 | Security Architecture for the Internet Protocol |
| |
|
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2402 | IP Authentication Header |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2403 | The Use of HMAC-MD5-96 within ESP and AH |
| |
| Authors: | C. Madson, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2403 |
|
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 |
| |
| Authors: | C. Madson, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2404 |
|
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 EncapsulatingSecurity 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 |
| |
| Authors: | C. Madson, N. Doraswamy. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2405 |
|
This document describes the use of the DES Cipher algorithm in CipherBlock Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating SecurityPayload (ESP). |
|
| |
| RFC 2406 | IP Encapsulating Security Payload (ESP) |
| |
|
|
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK] |
|
| |
| RFC 2407 | The Internet IP Security Domain of Interpretation for ISAKMP |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2408 | Internet Security Association and Key Management Protocol (ISAKMP) |
| |
| Authors: | D. Maughan, M. Schertler, M. Schneider, J. Turner. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4306 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2408 |
|
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 KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity 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 anInternet environment. |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
|
|
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] |
|
| |
| RFC 2410 | The NULL Encryption Algorithm and Its Use With IPsec |
| |
| Authors: | R. Glenn, S. Kent. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2410 |
|
This memo defines the NULL encryption algorithm and its use with theIPsec 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 |
| |
| Authors: | R. Thayer, N. Doraswamy, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6071 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2411 |
|
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 AuthenticationAlgorithm documents are described. |
|
| |
| RFC 2412 | The OAKLEY Key Determination Protocol |
| |
| Authors: | H. Orman. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2412 |
|
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 |
| |
| Authors: | S. Weibel, J. Kunze, C. Lagoze, M. Wolf. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5013 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2413 |
|
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. This memo provides information for the Internet community. |
|
| |
| RFC 2414 | Increasing TCP's Initial Window |
| |
| Authors: | M. Allman, S. Floyd, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3390 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2414 |
|
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 |
| |
| Authors: | K. Poduri, K. Nichols. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2415 |
|
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 |
| |
| Authors: | T. Shepard, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2416 |
|
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 |
| |
| Authors: | C. Chung, M. Greene. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2366 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2417 |
|
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 UNI3.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 |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. 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 InternetEngineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF AreaDirectors. |
|
| |
| RFC 2419 | The PPP DES Encryption Protocol, Version 2 (DESE-bis) |
| |
| Authors: | K. Sklower, G. Meyer. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoletes: | RFC 1969 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2419 |
|
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) |
| |
| Authors: | H. Kummert. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2420 |
|
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 |
| |
|
|
This document profiles Internet mail for voice messaging. [STANDARDS- TRACK] |
|
| |
| RFC 2422 | Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration |
| |
|
|
This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK] |
|
| |
| RFC 2423 | VPIM Voice Message MIME Sub-type Registration |
| |
|
|
This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK] |
|
| |
| RFC 2424 | Content Duration MIME Header Definition |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3803 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2424 |
|
This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK] |
|
| |
| RFC 2425 | A MIME Content-Type for Directory Information |
| |
| Authors: | T. Howes, M. Smith, F. Dawson. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2425 |
|
This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK] |
|
| |
| RFC 2426 | vCard MIME Directory Profile |
| |
| Authors: | F. Dawson, T. Howes. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2426 |
|
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 |
| |
|
|
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 |
| |
| Authors: | M. Allman, S. Ostermann, C. Metz. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2428 |
|
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 theInternet 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 |
| |
| Authors: | H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. |
| Date: | October 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4629 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2429 |
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2430 | A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) |
| |
| Authors: | T. Li, Y. Rekhter. |
| Date: | October 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2430 |
|
This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community. |
|
| |
| RFC 2431 | RTP Payload Format for BT.656 Video Encoding |
| |
| Authors: | D. Tynan. |
| Date: | October 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2431 |
|
This document specifies the RTP payload format for encapsulating ITURecommendation BT.656-3 video streams in the Real-Time TransportProtocol (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 |
| |
| Authors: | K. Dubray. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2432 |
|
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 BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology 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 |
| |
| Authors: | G. Zorn, S. Cobb. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2433 |
|
The Point-to-Point Protocol (PPP) 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 memo provides information for the Internet community. |
|
| |
| RFC 2434 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
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 NumbersAuthority (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 |
| |
| Authors: | L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart. |
| Date: | October 1998 |
| Formats: | txt json html |
| Obsoletes: | RFC 2035 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2435 |
|
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 |
| |
| Authors: | R. Brett, S. Bradner, G. Parsons. |
| Date: | October 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3356 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2436 |
|
This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community. |
|
| |
| RFC 2437 | PKCS #1: RSA Cryptography Specifications Version 2.0 |
| |
|
|
This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community. |
|
| |
| RFC 2438 | Advancement of MIB specifications on the IETF Standards Track |
| |
| Authors: | M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. |
| Date: | October 1998 |
| Formats: | txt json html |
| Also: | BCP 0027 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2438 |
|
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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2439 | BGP Route Flap Damping |
| |
| Authors: | C. Villamizar, R. Chandra, R. Govindan. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2439 |
|
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 |
| |
| Authors: | J. Callas, L. Donnerhacke, H. Finney, R. Thayer. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2440 |
|
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP 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 inOpenPGP. |
|
| |
| RFC 2441 | Working with Jon, Tribute delivered at UCLA, October 30, 1998 |
| |
| Authors: | D. Cohen. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2441 |
|
This memo provides information for the Internet community. |
|
| |
| RFC 2442 | The Batch SMTP Media Type |
| |
| Authors: | N. Freed, D. Newman, J. Belissent, M. Hoy. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2442 |
|
This document defines a MIME content type suitable for tunneling anESMTP [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 asNOTARY [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 |
| |
| Authors: | J. Luciani, A. Gallo. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2443 |
|
This document describes a method for distributing a MARS service within a LIS[1]. This method uses the Server Cache SynchronizationProtocol (SCSP)[2] to synchronize the MARS Server databases within aLIS. 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 |
| |
|
|
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) |
| |
| Authors: | F. Dawson, D. Stenerson. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5545 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2445 |
|
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 theInternet.
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.
This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification.
This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol. |
|
| |
| RFC 2446 | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
| |
| Authors: | S. Silverberg, S. Mansour, F. Dawson, R. Hopson. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5546 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2446 |
|
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) |
| |
| Authors: | F. Dawson, S. Mansour, S. Silverberg. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6047 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2447 |
|
This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject 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 EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. |
|
| |
| RFC 2448 | AT&T's Error Resilient Video Transmission Technique |
| |
| Authors: | M. Civanlar, G. Cash, B. Haskell. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2448 |
|
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 |
| |
|
|
This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK] |
|
| |
| RFC 2450 | Proposed TLA and NLA Assignment Rule |
| |
| Authors: | R. Hinden. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2450 |
|
This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community. |
|
| |
| RFC 2451 | The ESP CBC-Mode Cipher Algorithms |
| |
| Authors: | R. Pereira, R. Adams. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2451 |
|
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 |
| |
|
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl 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 whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2453 | RIP Version 2 |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (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 |
| |
|
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the UserDatagram 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 whichIP versions underlie UDP, and only the UDP listener information is IP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2455 | Definitions of Managed Objects for APPN |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2455 |
|
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 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2456 |
|
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 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2457 |
|
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 |
| |
| Authors: | H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2458 |
|
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public SwitchedTelephone Network (PSTN)/Internet Inter-Networking (PINT) WorkingGroup. 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 andPSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over thePSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of thePINT 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 |
| |
| Authors: | R. Housley, W. Ford, W. Polk, D. Solo. |
| Date: | January 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2459 |
|
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 |
| |
|
|
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) |
| |
|
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 2462 | IPv6 Stateless Address Autoconfiguration |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2465 | Management Information Base for IP Version 6: Textual Conventions and General Group |
| |
|
|
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 peerSNMPv1 definitions. |
|
| |
| RFC 2466 | Management Information Base for IP Version 6: ICMPv6 Group |
| |
|
|
This document is one in the series of documents that define variousMIB 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 peerSNMPv1 definitions. |
|
| |
| RFC 2467 | Transmission of IPv6 Packets over FDDI Networks |
| |
|
|
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. [STANDARDS- TRACK] |
|
| |
| RFC 2468 | I REMEMBER IANA |
| |
| Authors: | V. Cerf. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2468 |
|
A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community. |
|
| |
| RFC 2469 | A Caution On The Canonical Ordering Of Link-Layer Addresses |
| |
| Authors: | T. Narten, C. Burton. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2469 |
|
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 |
| |
| Authors: | M. Crawford, T. Narten, S. Thomas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2470 |
|
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK] |
|
| |
| RFC 2471 | IPv6 Testing Address Allocation |
| |
|
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2472 | IP Version 6 over PPP |
| |
|
|
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 |
| |
| Authors: | A. Conta, S. Deering. |
| Date: | December 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2473 |
|
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 |
| |
|
|
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.
For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH]. |
|
| |
| RFC 2475 | An Architecture for Differentiated Services |
| |
| Authors: | S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. |
| Date: | December 1998 |
| Formats: | txt html json |
| Updated by: | RFC 3260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2475 |
|
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 |
| |
| Authors: | R. Gellens, J. Klensin. |
| Date: | December 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4409 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2476 |
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2477 | Criteria for Evaluating Roaming Protocols |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2477 |
|
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. This memo provides information for the Internet community. |
|
| |
| RFC 2478 | The Simple and Protected GSS-API Negotiation Mechanism |
| |
| Authors: | E. Baize, D. Pinkas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4178 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2478 |
|
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK] |
|
| |
| RFC 2479 | Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) |
| |
| Authors: | C. Adams. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2479 |
|
The IDUP-GSS-API extends the GSS-API 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. This memo provides information for the Internet community. |
|
| |
| RFC 2480 | Gateways and MIME Security Multiparts |
| |
| Authors: | N. Freed. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2480 |
|
This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK] |
|
| |
| RFC 2481 | A Proposal to add Explicit Congestion Notification (ECN) to IP |
| |
| Authors: | K. Ramakrishnan, S. Floyd. |
| Date: | January 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3168 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2481 |
|
This note describes a proposed addition of ECN (Explicit CongestionNotification) 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 CongestionExperienced (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 |
| |
|
|
This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community. |
|
| |
| RFC 2483 | URI Resolution Services Necessary for URN Resolution |
| |
| Authors: | M. Mealling, R. Daniel. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2483 |
|
Retrieving the resource identified by a Uniform Resource Identifier(URI) [1] is only one of the operations that can be performed on aURI. 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 bothUniform 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 |
| |
|
|
The Point-to-Point Protocol (PPP) 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. [STANDARDS-TRACK] |
|
| |
| RFC 2485 | DHCP Option for The Open Group's User Authentication Protocol |
| |
| Authors: | S. Drach. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2485 |
|
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 GroupNetwork Computing Client Technical Standard [2]. |
|
| |
| RFC 2486 | The Network Access Identifier |
| |
| Authors: | B. Aboba, M. Beadles. |
| Date: | January 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4282 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2486 |
|
This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2487 | SMTP Service Extension for Secure SMTP over TLS |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2488 | Enhancing TCP Over Satellite Channels using Standard Mechanisms |
| |
| Authors: | M. Allman, D. Glover, L. Sanchez. |
| Date: | January 1999 |
| Formats: | txt html json |
| Also: | BCP 0028 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2488 |
|
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 |
| |
|
|
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 |
| |
| Authors: | M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. |
| Date: | January 1999 |
| Formats: | txt pdf html json ps |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2490 |
|
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 |
| |
| Authors: | G. Armitage, P. Schulter, M. Jork, G. Harter. |
| Date: | January 1999 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2491 |
|
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 NeighborDiscovery protocol operation within Logical Links, and inter-routerNHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported. |
|
| |
| RFC 2492 | IPv6 over ATM Networks |
| |
| Authors: | G. Armitage, P. Schulter, M. Jork. |
| Date: | January 1999 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2492 |
|
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 |
| |
|
|
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 |
| |
| Authors: | D. Fowler, Ed.. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2494 |
|
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 DS0Bundle interfaces. This document is a companion document withDefinitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]),DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH InterfaceTypes.
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 |
| |
|
|
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 withDefinitions 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 |
| |
|
|
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 (RFC2495 [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 |
| |
|
|
This memo specifies a frame format for transmission of 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, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK] |
|
| |
| RFC 2498 | IPPM Metrics for Measuring Connectivity |
| |
|
|
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. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2499 | Request for Comments Summary |
| |
| Authors: | A. Ramos. |
| Date: | July 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2499 |
|
|
|
