| |
| RFC 2700 | Internet Official Protocol Standards |
| |
|
|
This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering TaskForce (IETF). Sections 3.1 - 3.6 contain the lists of protocols in each stage of standardization - Standard, Draft Standard, ProposedStandard, Experimental and Historic. Protocols that are new to this document or have been moved from one protocol level to another, or differ from the previous edition of this document are marked.Informational Request for Comments (RFCs) are not included. This memo lists the current protocols; it is not a complete index to RFCs. |
|
| |
| RFC 2701 | Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol |
| |
| Authors: | G. Malkin. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2701 |
|
This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified. |
|
| |
| RFC 2702 | Requirements for Traffic Engineering Over MPLS |
| |
| Authors: | D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2702 |
|
This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics. |
|
| |
| RFC 2703 | Protocol-independent Content Negotiation Framework |
| |
| Authors: | G. Klyne. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2703 |
|
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers.
This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.
The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism. |
|
| |
| RFC 2704 | The KeyNote Trust-Management System Version 2 |
| |
| Authors: | M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2704 |
|
This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. TheKeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services. |
|
| |
| RFC 2705 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. |
| Date: | October 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2705 |
|
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
|
| |
| RFC 2706 | ECML v1: Field Names for E-Commerce |
| |
| Authors: | D. Eastlake 3rd, T. Goldstein. |
| Date: | October 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3106 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2706 |
|
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. |
|
| |
| RFC 2707 | Job Monitoring MIB - V1.0 |
| |
| Authors: | R. Bergman, T. Hastings, S. Isaacson, H. Lewis. |
| Date: | November 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2707 |
|
This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job.This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. |
|
| |
| RFC 2708 | Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB |
| |
| Authors: | R. Bergman. |
| Date: | November 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2708 |
|
This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the JobMonitoring MIB. |
|
| |
| RFC 2709 | Security Model with Tunnel-mode IPsec for NAT Domains |
| |
| Authors: | P. Srisuresh. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2709 |
|
There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described. |
|
| |
| RFC 2710 | Multicast Listener Discovery (MLD) for IPv6 |
| |
|
|
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as MulticastListener Discovery or MLD. MLD is derived from version 2 of IPv4'sInternet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. |
|
| |
| RFC 2711 | IPv6 Router Alert Option |
| |
| Authors: | C. Partridge, A. Jackson. |
| Date: | October 1999 |
| Formats: | txt html json |
| Updated by: | RFC 6398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2711 |
|
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. |
|
| |
| RFC 2712 | Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) |
| |
| Authors: | A. Medvinsky, M. Hur. |
| Date: | October 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2712 |
|
This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS TRACK] |
|
| |
| RFC 2713 | Schema for Representing Java(tm) Objects in an LDAP Directory |
| |
| Authors: | V. Ryan, S. Seligman, R. Lee. |
| Date: | October 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2713 |
|
This document defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to represent a Java serialized object [Serial], a Java marshalled object [RMI], aJava remote object [RMI], and a JNDI reference [JNDI]. |
|
| |
| RFC 2714 | Schema for Representing CORBA Object References in an LDAP Directory |
| |
| Authors: | V. Ryan, R. Lee, S. Seligman. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2714 |
|
CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory[LDAPv3]. |
|
| |
| RFC 2715 | Interoperability Rules for Multicast Routing Protocols |
| |
| Authors: | D. Thaler. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2715 |
|
The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.Specific instantiations of these rules are given for the DVMRP,MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them. |
|
| |
| RFC 2716 | PPP EAP TLS Authentication Protocol |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2717 | Registration Procedures for URL Scheme Names |
| |
| Authors: | R. Petke, I. King. |
| Date: | November 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4395 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2717 |
|
This document defines the process by which new URL scheme names are registered. |
|
| |
| RFC 2718 | Guidelines for new URL Schemes |
| |
| Authors: | L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. |
| Date: | November 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4395 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2718 |
|
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes. |
|
| |
| RFC 2719 | Framework Architecture for Signaling Transport |
| |
| Authors: | L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2719 |
|
This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols. |
|
| |
| RFC 2720 | Traffic Flow Measurement: Meter MIB |
| |
|
|
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'.
This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. |
|
| |
| RFC 2721 | RTFM: Applicability Statement |
| |
| Authors: | N. Brownlee. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2721 |
|
This document provides an overview covering all aspects of RealtimeTraffic Flow Measurement, including its area of applicability and its limitations. |
|
| |
| RFC 2722 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | October 1999 |
| Formats: | txt json html |
| Obsoletes: | RFC 2063 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2722 |
|
This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within theInternet. |
|
| |
| RFC 2723 | SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups |
| |
| Authors: | N. Brownlee. |
| Date: | October 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2723 |
|
This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. |
|
| |
| RFC 2724 | RTFM: New Attributes for Traffic Flow Measurement |
| |
| Authors: | S. Handelman, S. Stibler, N. Brownlee, G. Ruth. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2724 |
|
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.
Extensions described include Address Attributes such as DSCodePoint,SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters forIntegrated Services are also discussed. |
|
| |
| RFC 2725 | Routing Policy System Security |
| |
| Authors: | C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. |
| Date: | December 1999 |
| Formats: | txt html json |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2725 |
|
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. |
|
| |
| RFC 2726 | PGP Authentication for RIPE Database Updates |
| |
| Authors: | J. Zsako. |
| Date: | December 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2726 |
|
This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force. |
|
| |
| RFC 2727 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 2728 | The Transmission of IP Over the Vertical Blanking Interval of a Television Signal |
| |
| Authors: | R. Panabaker, S. Wegerif, D. Zigmond. |
| Date: | November 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2728 |
|
This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS TRACK] |
|
| |
| RFC 2729 | Taxonomy of Communication Requirements for Large-scale Multicast Applications |
| |
| Authors: | P. Bagnall, R. Briscoe, A. Poppitt. |
| Date: | December 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2729 |
|
The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this.Classification is a first step towards standardization. |
|
| |
| RFC 2730 | Multicast Address Dynamic Client Allocation Protocol (MADCAP) |
| |
| Authors: | S. Hanna, B. Patel, M. Shah. |
| Date: | December 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2730 |
|
This document defines a protocol, Multicast Address Dynamic ClientAllocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. |
|
| |
| RFC 2731 | Encoding Dublin Core Metadata in HTML |
| |
|
|
The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community. |
|
| |
| RFC 2732 | Format for Literal IPv6 Addresses in URL's |
| |
|
|
This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol.
This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose. |
|
| |
| RFC 2733 | An RTP Payload Format for Generic Forward Error Correction |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | December 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2733 |
|
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. |
|
| |
| RFC 2734 | IPv4 over IEEE 1394 |
| |
| Authors: | P. Johansson. |
| Date: | December 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2734 |
|
This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS TRACK] |
|
| |
| RFC 2735 | NHRP Support for Virtual Private Networks |
| |
| Authors: | B. Fox, B. Petri. |
| Date: | December 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2735 |
|
The NBMA Next Hop Resolution Protocol (NHRP) is used to determine theNBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. |
|
| |
| RFC 2736 | Guidelines for Writers of RTP Payload Format Specifications |
| |
|
|
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. |
|
| |
| RFC 2737 | Entity MIB (Version 2) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. |
|
| |
| RFC 2738 | Corrections to "A Syntax for Describing Media Feature Sets" |
| |
|
|
In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. |
|
| |
| RFC 2739 | Calendar Attributes for vCard and LDAP |
| |
| Authors: | T. Small, D. Hennessy, F. Dawson. |
| Date: | January 2000 |
| Formats: | txt html json |
| Updated by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2739 |
|
When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event.
In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time.
This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include:
- Manual transfer of the information;
- Personal data exchange using the vCard format; and
- Directory lookup using the LDAP protocol. |
|
| |
| RFC 2740 | OSPF for IPv6 |
| |
| Authors: | R. Coltun, D. Ferguson, J. Moy. |
| Date: | December 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5340 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2740 |
|
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6. |
|
| |
| RFC 2741 | Agent Extensibility (AgentX) Protocol Version 1 |
| |
| Authors: | M. Daniele, B. Wijnen, M. Ellison, D. Francisco. |
| Date: | January 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2257 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2741 |
|
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processesSNMP protocol messages. This memo obsoletes RFC 2257. |
|
| |
| RFC 2742 | Definitions of Managed Objects for Extensible SNMP Agents |
| |
| Authors: | L. Heintz, S. Gudur, M. Ellison. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2742 |
|
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 managing SNMP agents that use theAgent Extensibility (AgentX) Protocol.
This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions. |
|
| |
| RFC 2743 | Generic Security Service Application Program Interface Version 2, Update 1 |
| |
|
|
The Generic Security Service Application Program Interface (GSS-API),Version 2, as defined in [RFC-2078], 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 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: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. |
|
| |
| RFC 2744 | Generic Security Service API Version 2 : C-bindings |
| |
|
|
This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC-2743 [GSSAPI]. It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track.
The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
|
| |
| RFC 2745 | RSVP Diagnostic Messages |
| |
| Authors: | A. Terzis, B. Braden, S. Vincent, L. Zhang. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2745 |
|
This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules. |
|
| |
| RFC 2746 | RSVP Operation Over IP Tunnels |
| |
| Authors: | A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2746 |
|
This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals. |
|
| |
| RFC 2747 | RSVP Cryptographic Authentication |
| |
| Authors: | F. Baker, B. Lindell, M. Talwar. |
| Date: | January 2000 |
| Formats: | txt html json |
| Updated by: | RFC 3097 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2747 |
|
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. |
|
| |
| RFC 2748 | The COPS (Common Open Policy Service) Protocol |
| |
| Authors: | D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. |
| Date: | January 2000 |
| Formats: | txt json html |
| Updated by: | RFC 4261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2748 |
|
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies. |
|
| |
| RFC 2749 | COPS usage for RSVP |
| |
| Authors: | S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2749 |
|
This document describes usage directives for supporting COPS policy services in RSVP environments. |
|
| |
| RFC 2750 | RSVP Extensions for Policy Control |
| |
|
|
This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]
These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.
This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP]. |
|
| |
| RFC 2751 | Signaled Preemption Priority Policy Element |
| |
|
|
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]).
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. |
|
| |
| RFC 2752 | Identity Representation for RSVP |
| |
| Authors: | S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. |
| Date: | January 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2752 |
|
This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. |
|
| |
| RFC 2753 | A Framework for Policy-based Admission Control |
| |
| Authors: | R. Yavatkar, D. Pendarakis, R. Guerin. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2753 |
|
This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community. |
|
| |
| RFC 2754 | RPS IANA Issues |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, R. Govindan. |
| Date: | January 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6254 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2754 |
|
RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required fromIANA. |
|
| |
| RFC 2755 | Security Negotiation for WebNFS |
| |
| Authors: | A. Chiu, M. Eisler, B. Callaghan. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2755 |
|
This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server[RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations. |
|
| |
| RFC 2756 | Hyper Text Caching Protocol (HTCP/0.0) |
| |
| Authors: | P. Vixie, D. Wessels. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2756 |
|
This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. |
|
| |
| RFC 2757 | Long Thin Networks |
| |
| Authors: | G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2757 |
|
In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them. |
|
| |
| RFC 2758 | Definitions of Managed Objects for Service Level Agreements Performance Monitoring |
| |
| Authors: | K. White. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2758 |
|
This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data. |
|
| |
| RFC 2759 | Microsoft PPP CHAP Extensions, Version 2 |
| |
| Authors: | G. Zorn. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2759 |
|
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 NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document describes version two of Microsoft's PPP CHAP dialect(MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication.
The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9. |
|
| |
| RFC 2760 | Ongoing TCP Research Related to Satellites |
| |
| Authors: | M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2760 |
|
This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by theIETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks. |
|
| |
| RFC 2761 | Terminology for ATM Benchmarking |
| |
| Authors: | J. Dunn, C. Martin. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2761 |
|
This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined inRFCs 1242, 2285, and 2544. This memo is a product of the BenchmarkingMethodology Working Group (BMWG) of the Internet Engineering TaskForce (IETF). |
|
| |
| RFC 2762 | Sampling of the Group Membership in RTP |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | February 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2762 |
|
In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. |
|
| |
| RFC 2763 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
|
|
Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. |
|
| |
| RFC 2764 | A Framework for IP Based Virtual Private Networks |
| |
| Authors: | B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2764 |
|
This document describes a framework for Virtual Private Networks(VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions. |
|
| |
| RFC 2765 | Stateless IP/ICMP Translation Algorithm (SIIT) |
| |
|
|
This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. |
|
| |
| RFC 2766 | Network Address Translation - Protocol Translation (NAT-PT) |
| |
|
|
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT]. |
|
| |
| RFC 2767 | Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) |
| |
| Authors: | K. Tsuchiya, H. Higuchi, Y. Atarashi. |
| Date: | February 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2767 |
|
In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. |
|
| |
| RFC 2768 | Network Policy and Services: A Report of a Workshop on Middleware |
| |
| Authors: | B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2768 |
|
An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University'sInternational Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. |
|
| |
| RFC 2769 | Routing Policy System Replication |
| |
| Authors: | C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2769 |
|
The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System SecurityRFC. |
|
| |
| RFC 2770 | GLOP Addressing in 233/8 |
| |
| Authors: | D. Meyer, P. Lothberg. |
| Date: | February 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3180 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2770 |
|
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors. |
|
| |
| RFC 2771 | An Abstract API for Multicast Address Allocation |
| |
| Authors: | R. Finlayson. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2771 |
|
This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service. |
|
| |
| RFC 2772 | 6Bone Backbone Routing Guidelines |
| |
|
|
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. |
|
| |
| RFC 2773 | Encryption using KEA and SKIPJACK |
| |
| Authors: | R. Housley, P. Yee, W. Nace. |
| Date: | February 2000 |
| Formats: | txt html json |
| Updates: | RFC 0959 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2773 |
|
This document defines a method to encrypt a file transfer using theFTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.SKIPJACK is used to encrypt file data and the FTP command channel. |
|
| |
| RFC 2774 | An HTTP Extension Framework |
| |
| Authors: | H. Nielsen, P. Leach, S. Lawrence. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2774 |
|
A wide range of applications have proposed various extensions of theHTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication. |
|
| |
| RFC 2775 | Internet Transparency |
| |
| Authors: | B. Carpenter. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2775 |
|
This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations. |
|
| |
| RFC 2776 | Multicast-Scope Zone Announcement Protocol (MZAP) |
| |
| Authors: | M. Handley, D. Thaler, R. Kermode. |
| Date: | February 2000 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2776 |
|
This document defines a protocol, the Multicast-Scope ZoneAnnouncement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered. |
|
| |
| RFC 2777 | Publicly Verifiable Nomcom Random Selection |
| |
|
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases. |
|
| |
| RFC 2778 | A Model for Presence and Instant Messaging |
| |
| Authors: | M. Day, J. Rosenberg, H. Sugano. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2778 |
|
This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. |
|
| |
| RFC 2779 | Instant Messaging / Presence Protocol Requirements |
| |
| Authors: | M. Day, S. Aggarwal, G. Mohr, J. Vincent. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2779 |
|
Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.
Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and PresenceProtocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet. |
|
| |
| RFC 2780 | IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers |
| |
|
|
This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. |
|
| |
| RFC 2781 | UTF-16, an encoding of ISO 10646 |
| |
| Authors: | P. Hoffman, F. Yergeau. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2781 |
|
This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community. |
|
| |
| RFC 2782 | A DNS RR for specifying the location of services (DNS SRV) |
| |
|
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. |
|
| |
| RFC 2783 | Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 |
| |
| Authors: | J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2783 |
|
RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. |
|
| |
| RFC 2784 | Generic Routing Encapsulation (GRE) |
| |
|
|
This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. |
|
| |
| RFC 2785 | Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME |
| |
| Authors: | R. Zuccherato. |
| Date: | March 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2785 |
|
In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. |
|
| |
| RFC 2786 | Diffie-Helman USM Key Management Information Base and Textual Convention |
| |
| Authors: | M. St. Johns. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2786 |
|
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of aDH key exchange in addition to the key change method described in[12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential.
The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process.
The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16].
This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force.Comments are solicited and should be addressed to the the author. |
|
| |
| RFC 2787 | Definitions of Managed Objects for the Virtual Router Redundancy Protocol |
| |
| Authors: | B. Jewell, D. Chuang. |
| Date: | March 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2787 |
|
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router RedundancyProtocol (VRRP) [17].
This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2]. |
|
| |
| RFC 2788 | Network Services Monitoring MIB |
| |
|
|
This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS TRACK] |
|
| |
| RFC 2789 | Mail Monitoring MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS TRACK] |
|
| |
| RFC 2790 | Host Resources MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the HostResources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.
This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. |
|
| |
| RFC 2791 | Scalable Routing Design Principles |
| |
|
|
Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. |
|
| |
| RFC 2792 | DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System |
| |
| Authors: | M. Blaze, J. Ioannidis, A. Keromytis. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2792 |
|
This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. |
|
| |
| RFC 2793 | RTP Payload for Text Conversation |
| |
|
|
This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1].
Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.
This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. |
|
| |
| RFC 2794 | Mobile IP Network Access Identifier Extension for IPv4 |
| |
|
|
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers.Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. |
|
| |
| RFC 2795 | The Infinite Monkey Protocol Suite (IMPS) |
| |
| Authors: | S. Christey. |
| Date: | 1 April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2795 |
|
This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works ofWilliam Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them. |
|
| |
| RFC 2796 | BGP Route Reflection - An Alternative to Full Mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within thatAS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 2797 | Certificate Management Messages over CMS |
| |
| Authors: | M. Myers, X. Liu, J. Schaad, J. Weinstein. |
| Date: | April 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2797 |
|
This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys.
A small number of additional services are defined to supplement the core certificate request service.
Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. |
|
| |
| RFC 2798 | Definition of the inetOrgPerson LDAP Object Class |
| |
|
|
While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. |
|
| |
| RFC 2799 | Request for Comments Summary RFC Numbers 2700-2799 |
| |
| Authors: | S. Ginoza. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2799 |
|
|
|
