| |
| RFC 3000 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3001 | A URN Namespace of Object Identifiers |
| |
|
|
This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). |
|
| |
| RFC 3002 | Overview of 2000 IAB Wireless Internetworking Workshop |
| |
| Authors: | D. Mitzel. |
| Date: | December 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3002 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thruMarch 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community.
Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list. |
|
| |
| RFC 3003 | The audio/mpeg Media Type |
| |
| Authors: | M. Nilsson. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3003 |
|
The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose InternetMail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. |
|
| |
| RFC 3004 | The User Class Option for DHCP |
| |
| Authors: | G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. |
| Date: | November 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3004 |
|
This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. |
|
| |
| RFC 3005 | IETF Discussion List Charter |
| |
|
|
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed.Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. |
|
| |
| RFC 3006 | Integrated Services in the Presence of Compressible Flows |
| |
| Authors: | B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3006 |
|
An Integrated Services (int-serv) router performs admission control and resource allocation based on the information contained in a TSpec(among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing real-time transport protocol(RTP) header compression that they may allocate fewer resources toRTP flows. |
|
| |
| RFC 3007 | Secure Domain Name System (DNS) Dynamic Update |
| |
|
|
This document proposes a method for performing secure Domain NameSystem (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. |
|
| |
| RFC 3008 | Domain Name System Security (DNSSEC) Signing Authority |
| |
|
|
This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. |
|
| |
| RFC 3009 | Registration of parityfec MIME types |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | November 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3009 |
|
The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. |
|
| |
| RFC 3010 | NFS version 4 Protocol |
| |
| Authors: | S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. |
| Date: | December 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3010 |
|
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. |
|
| |
| RFC 3011 | The IPv4 Subnet Selection Option for DHCP |
| |
| Authors: | G. Waters. |
| Date: | November 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3011 |
|
This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address.This option would override a DHCP server's normal methods of selecting the subnet on which to allocate an address for a client. |
|
| |
| RFC 3012 | Mobile IPv4 Challenge/Response Extensions |
| |
| Authors: | C. Perkins, P. Calhoun. |
| Date: | November 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4721 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3012 |
|
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. |
|
| |
| RFC 3013 | Recommended Internet Service Provider Security Services and Procedures |
| |
|
|
The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet ServiceProviders (ISPs) with respect to security.
It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers. |
|
| |
| RFC 3014 | Notification Log MIB |
| |
| Authors: | R. Kavasseri. |
| Date: | November 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3014 |
|
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 logging SimpleNetwork Management Protocol (SNMP) Notifications. |
|
| |
| RFC 3015 | Megaco Protocol Version 1.0 |
| |
|
|
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 3016 | RTP Payload Format for MPEG-4 Audio/Visual Streams |
| |
| Authors: | Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. |
| Date: | November 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6416 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3016 |
|
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). |
|
| |
| RFC 3017 | XML DTD for Roaming Access Phone Book |
| |
| Authors: | M. Riegel, G. Zorn. |
| Date: | December 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3017 |
|
This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. It comprises the information necessary to select the most appropriate ISP and to configure the host to get access to the network of the provider. The specification consists of a small set of required information elements and a variety of possible extensions.All data is specified in XML [5] (Extensible Markup Language) syntax leading to a concise XML DTD (Document Type Declaration) for the phone book. |
|
| |
| RFC 3018 | Unified Memory Space Protocol Specification |
| |
| Authors: | A. Bogdanov. |
| Date: | December 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3018 |
|
This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. |
|
| |
| RFC 3019 | IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol |
| |
| Authors: | B. Haberman, R. Worzella. |
| Date: | January 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3019 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710]. |
|
| |
| RFC 3020 | Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function |
| |
| Authors: | P. Pate, B. Lynch, K. Rehbehn. |
| Date: | December 2000 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3020 |
|
This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information. |
|
| |
| RFC 3021 | Using 31-Bit Prefixes on IPv4 Point-to-Point Links |
| |
| Authors: | A. Retana, R. White, V. Fuller, D. McPherson. |
| Date: | December 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3021 |
|
With ever-increasing pressure to conserve IP address space on theInternet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout theInternet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. |
|
| |
| RFC 3022 | Traditional IP Network Address Translator (Traditional NAT) |
| |
| Authors: | P. Srisuresh, K. Egevang. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoletes: | RFC 1631 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3022 |
|
Basic Network Address Translation or Basic NAT is a method by whichIP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission ControlProtocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses. |
|
| |
| RFC 3023 | XML Media Types |
| |
|
|
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be". |
|
| |
| RFC 3024 | Reverse Tunneling for Mobile IP, revised |
| |
|
|
Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.
This document obsoletes RFC 2344. |
|
| |
| RFC 3025 | Mobile IP Vendor/Organization-Specific Extensions |
| |
| Authors: | G. Dommety, K. Leung. |
| Date: | February 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3115 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3025 |
|
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. |
|
| |
| RFC 3026 | Liaison to IETF/ISOC on ENUM |
| |
| Authors: | R. Blane. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3026 |
|
Working Party 1/2, of the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. The agenda of the meeting contained several contributions regarding RFC 2916:"E.164 Number and DNS" from the Internet Engineering Task Force's(IETF) ENUM Working Group - more specifically, the method for administering and maintaining the E.164-based resources in the DomainName System (DNS) as related to the ENUM protocol. Consequently, in addition to the WP1/2 collaborators, there were several members of the IETF present to assist with the discussion of issues contained in the aforementioned contributions.
This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. |
|
| |
| RFC 3027 | Protocol Complications with the IP Network Address Translator |
| |
| Authors: | M. Holdrege, P. Srisuresh. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3027 |
|
Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IPNetwork Address Translator (NAT) enroute to bridge the realms. TheNAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of ApplicationLevel Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered. |
|
| |
| RFC 3028 | Sieve: A Mail Filtering Language |
| |
|
|
This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 3029 | Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols |
| |
| Authors: | C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3029 |
|
This document describes a general Data Validation and CertificationServer (DVCS) and the protocols to be used when communicating with it. The Data Validation and Certification Server is a Trusted ThirdParty (TTP) that can be used as one component in building reliable non-repudiation services.
Useful Data Validation and Certification Server responsibilities in aPKI are to assert the validity of signed documents, public key certificates, and the possession or existence of data.
Assertions created by this protocol are called Data ValidationCertificates (DVC).
We give examples of how to use the Data Validation and CertificationServer to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Validation and Certification Server regarding the status of a public key certificate. The document includes a complete example of a time stamping transaction. |
|
| |
| RFC 3030 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages |
| |
|
|
This memo defines two extensions to the SMTP (Simple Mail TransferProtocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (MultipurposeInternet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending ofMIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830. |
|
| |
| RFC 3031 | Multiprotocol Label Switching Architecture |
| |
|
|
This document specifies the architecture for Multiprotocol LabelSwitching (MPLS). |
|
| |
| RFC 3032 | MPLS Label Stack Encoding |
| |
| Authors: | E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. |
| Date: | January 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3032 |
|
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. |
|
| |
| RFC 3033 | The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol |
| |
| Authors: | M. Suzuki. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3033 |
|
The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 GenericIdentifier and Q.2957 User-to-user Signaling for the Internet protocol.
The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM. |
|
| |
| RFC 3034 | Use of Label Switching on Frame Relay Networks Specification |
| |
| Authors: | A. Conta, P. Doolan, A. Malis. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3034 |
|
This document defines the model and generic mechanisms forMultiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol LabelSwitching Architecture described in [ARCH] and the Label DistributionProtocol (LDP) described in [LDP] relative to Frame Relay Networks.MPLS enables the use of Frame Relay Switches as Label SwitchingRouters (LSRs). |
|
| |
| RFC 3035 | MPLS using LDP and ATM VC Switching |
| |
| Authors: | B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3035 |
|
The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used asLabel Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), IntermediateSystem to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. NoATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).
This document extends and clarifies the relevant portions of [1] and[2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels representForwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3]. |
|
| |
| RFC 3036 | LDP Specification |
| |
| Authors: | L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5036 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3036 |
|
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 3037 | LDP Applicability |
| |
| Authors: | B. Thomas, E. Gray. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3037 |
|
Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP(for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 3038 | VCID Notification over ATM link for LDP |
| |
| Authors: | K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. |
| Date: | January 2001 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3038 |
|
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. |
|
| |
| RFC 3039 | Internet X.509 Public Key Infrastructure Qualified Certificates Profile |
| |
| Authors: | S. Santesson, W. Polk, P. Barzin, M. Nystrom. |
| Date: | January 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3739 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3039 |
|
This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs.
It is important to note that the profile does not define any legal requirements for Qualified Certificates. |
|
| |
| RFC 3040 | Internet Web Replication and Caching Taxonomy |
| |
| Authors: | I. Cooper, I. Melve, G. Tomlinson. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3040 |
|
This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in the document titled"Known HTTP Proxy/Caching Problems", and are not part of this document. This document presents open protocols and points to published material for each protocol. |
|
| |
| RFC 3041 | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
| Authors: | T. Narten, R. Draves. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3041 |
|
Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. |
|
| |
| RFC 3042 | Enhancing TCP's Loss Recovery Using Limited Transmit |
| |
| Authors: | M. Allman, H. Balakrishnan, S. Floyd. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3042 |
|
This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The"Limited Transmit" algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. Transmitting these segments increases the probability that TCP can recover from a single lost segment using the fast retransmit algorithm, rather than using a costly retransmission timeout. Limited Transmit can be used both in conjunction with, and in the absence of, the TCP selective acknowledgment (SACK) mechanism. |
|
| |
| RFC 3043 | The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations |
| |
| Authors: | M. Mealling. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3043 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. |
|
| |
| RFC 3044 | Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace |
| |
|
|
This document presents how the ISSN - International Standard SerialNumber - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier.
An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by theISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment.
This proceeds from concepts and proposals developed in several IETFRFCs emphasising the way to implement and to use "recognised" existing numbering system within the URN framework (RFC 2248, RFC2141, RFC 2611). |
|
| |
| RFC 3045 | Storing Vendor Information in the LDAP root DSE |
| |
| Authors: | M. Meredith. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3045 |
|
This document specifies two Lightweight Directory Access Protocol(LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251.
The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery. |
|
| |
| RFC 3046 | DHCP Relay Agent Information Option |
| |
|
|
Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use theDynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.However, a number of security and scaling problems arise with such"public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132.
The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originatedDHCP packets to a DHCP server. Servers recognizing the Relay AgentInformation option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.
The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem. |
|
| |
| RFC 3047 | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP. |
|
| |
| RFC 3048 | Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
| |
| Authors: | B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3048 |
|
This document describes a framework for the standardization of bulk- data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores".Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols. |
|
| |
| RFC 3049 | TN3270E Service Location and Session Balancing |
| |
| Authors: | J. Naugle, K. Kasthurirangan, G. Ledford. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3049 |
|
This document discusses the implementation of Service LocationProtocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server.
Application program developer's can locate TN3270E services and load balance among those services (3270 host sessions), by using this SLP support. |
|
| |
| RFC 3050 | Common Gateway Interface for SIP |
| |
| Authors: | J. Lennox, H. Schulzrinne, J. Rosenberg. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3050 |
|
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the CommonGateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between theSession Initiation Protocol (SIP) and the Hyper Text TransferProtocol (HTTP), CGI is a good candidate for service creation in aSIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server. |
|
| |
| RFC 3051 | IP Payload Compression Using ITU-T V.44 Packet Method |
| |
| Authors: | J. Heath, J. Border. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3051 |
|
This document describes a compression method based on the data compression algorithm described in International TelecommunicationUnion (ITU-T) Recommendation V.44. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g., V.44 Packet Method).This document defines the application of V.44 Packet Method to theInternet Protocol (IP) Payload Compression Protocol (RFC 2393). RFC2393 defines a method for applying lossless compression to the payload portion of IP datagrams.
V.44 Packet Method is based upon the LZJH data compression algorithm.Throughout the remainder of this document the terms V.44 PacketMethod and LZJH are synonymous. |
|
| |
| RFC 3052 | Service Management Architectures Issues and Review |
| |
| Authors: | M. Eder, S. Nag. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3052 |
|
Many of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. |
|
| |
| RFC 3053 | IPv6 Tunnel Broker |
| |
| Authors: | A. Durand, P. Fasano, I. Guardini, D. Lento. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3053 |
|
The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network(e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented atOrlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting inFebruary 1999. |
|
| |
| RFC 3054 | Megaco IP Phone Media Gateway Application Profile |
| |
| Authors: | P. Blatherwick, R. Bell, P. Holland. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3054 |
|
This document specifies a particular application of the Megaco/H.248Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a MediaGateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media GatewayController (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations andPackages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface relatedPackages, and is thus a straight-forward application of theMegaco/H.248 Protocol. |
|
| |
| RFC 3055 | Management Information Base for the PINT Services Architecture |
| |
| Authors: | M. Krishnaswamy, D. Romascanu. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3055 |
|
This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. |
|
| |
| RFC 3056 | Connection of IPv6 Domains via IPv4 Clouds |
| |
| Authors: | B. Carpenter, K. Moore. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3056 |
|
This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence ofIPv4 and IPv6. It is not intended as a permanent solution.
The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network.
The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally uniqueIPv6 address prefix to any site with at least one globally uniqueIPv4 address, even if combined with an IPv4 Network AddressTranslator (NAT). |
|
| |
| RFC 3057 | ISDN Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | February 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3057 |
|
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. |
|
| |
| RFC 3058 | Use of the IDEA Encryption Algorithm in CMS |
| |
| Authors: | S. Teiwes, P. Hartmann, D. Kuenzi. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3058 |
|
This memo specifies how to incorporate International Data EncryptionAlgorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide theOIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. |
|
| |
| RFC 3059 | Attribute List Extension for the Service Location Protocol |
| |
| Authors: | E. Guttman. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3059 |
|
The Service Location Protocol, Version 2 (SLPv2) provides a mechanism for a service to be discovered in a single exchange of messages.This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. |
|
| |
| RFC 3060 | Policy Core Information Model -- Version 1 Specification |
| |
| Authors: | B. Moore, E. Ellesson, J. Strassner, A. Westerinen. |
| Date: | February 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3060 |
|
This document presents the object-oriented information model for representing policy information developed jointly in the IETF PolicyFramework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. |
|
| |
| RFC 3061 | A URN Namespace of Object Identifiers |
| |
|
|
This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). It obsoletes RFC 3001. |
|
| |
| RFC 3062 | LDAP Password Modify Extended Operation |
| |
| Authors: | K. Zeilenga. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3062 |
|
The integration of the Lightweight Directory Access Protocol (LDAP) and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory (e.g.,Modify) cannot be used to change a user's password. This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. |
|
| |
| RFC 3063 | MPLS Loop Prevention Mechanism |
| |
| Authors: | Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3063 |
|
This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path- vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved. |
|
| |
| RFC 3064 | MGCP CAS Packages |
| |
| Authors: | B. Foster. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3064 |
|
This document contains a collection of media gateway ChannelAssociated Signaling (CAS) packages for R1 CAS, North American CAS,CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks.This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3].The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX(digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These includeEAIN and EANA which is covered by the enclosed "MD" package and theOperator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package. |
|
| |
| RFC 3065 | Autonomous System Confederations for BGP |
| |
|
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. |
|
| |
| RFC 3066 | Tags for the Identification of Languages |
| |
|
|
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. |
|
| |
| RFC 3067 | TERENA'S Incident Object Description and Exchange Format Requirements |
| |
| Authors: | J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3067 |
|
The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (ComputerSecurity Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements.Examples are used to illustrate the requirements where necessary. |
|
| |
| RFC 3068 | An Anycast Prefix for 6to4 Relay Routers |
| |
|
|
This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned NumbersAuthority) of the "6to4 relay anycast prefix." |
|
| |
| RFC 3069 | VLAN Aggregation for Efficient IP Address Allocation |
| |
| Authors: | D. McPherson, B. Dykes. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3069 |
|
This document introduces the concept of Virtual Local Area Network(VLAN) aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) orMetropolitan Area Network (MAN).
Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network. |
|
| |
| RFC 3070 | Layer Two Tunneling Protocol (L2TP) over Frame Relay |
| |
| Authors: | V. Rawat, R. Tio, S. Nanji, R. Verma. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3070 |
|
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnelPoint-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User DatagramProtocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent VirtualCircuits (PVCs) and Switched Virtual Circuits (SVCs). |
|
| |
| RFC 3071 | Reflections on the DNS, RFC 1591, and Categories of Domains |
| |
| Authors: | J. Klensin. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3071 |
|
RFC 1591, "Domain Name System Structure and Delegation", laid out the basic administrative design and principles for the allocation and administration of domains, from the top level down. It was written before the introduction of the world wide web (WWW) and rapid growth of the Internet put significant market, social, and political pressure on domain name allocations. In recent years, 1591 has been cited by all sides in various debates, and attempts have been made by various bodies to update it or adjust its provisions, sometimes under pressures that have arguably produced policies that are less well thought out than the original. Some of those efforts have begun from misconceptions about the provisions of 1591 or the motivation for those provisions. The current directions of the Internet Corporation for Assigned Names and Numbers (ICANN) and other groups who now determine the Domain Name System (DNS) policy directions appear to be drifting away from the policies and philosophy of 1591. This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how1591 might have been interpreted and adjusted by the InternetAssigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. An earlier variation of this memo was submitted to ICANN as a comment on its evolving Top-level Domain (TLD) policies. |
|
| |
| RFC 3072 | Structured Data Exchange Format (SDXF) |
| |
| Authors: | M. Wildgrube. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3072 |
|
This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent. |
|
| |
| RFC 3073 | Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration |
| |
| Authors: | J. Collins. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3073 |
|
This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification.
A Portable Font Resource (PFR) contains a set of glyph shapes. Each glyph shape is associated with a character code. The PFR format is designed to be both compact and platform-independent. It is intended to facilitate accurate rendering of fonts in all environments whether or not they have the required fonts already installed. |
|
| |
| RFC 3074 | DHC Load Balancing Algorithm |
| |
| Authors: | B. Volz, S. Gonczi, T. Lemon, R. Stevens. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3074 |
|
This document proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration.
The server selection is based on the servers hashing client MediaAccess Control (MAC) addresses when multiple Dynamic HostConfiguration Protocol (DHCP) servers are available to service DHCP clients. The proposed technique provides for efficient server selection when multiple DHCP servers offer services on a network without requiring any changes to existing DHCP clients. The same method is proposed to select the target server of a forwarding agent such as a Bootstrap Protocol (BOOTP) relay. |
|
| |
| RFC 3075 | XML-Signature Syntax and Processing |
| |
| Authors: | D. Eastlake 3rd, J. Reagle, D. Solo. |
| Date: | March 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3075 |
|
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. |
|
| |
| RFC 3076 | Canonical XML Version 1.0 |
| |
| Authors: | J. Boyer. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3076 |
|
Any XML (Extensible Markup Language) document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account. |
|
| |
| RFC 3077 | A Link-Layer Tunneling Mechanism for Unidirectional Links |
| |
| Authors: | E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3077 |
|
This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. The "receiver" uses a link-layer tunneling mechanism to forward datagrams to "feeds" over a separate bidirectional IP (Internet Protocol) network. As it is implemented at the link-layer, protocols in addition to IP may also be supported by this mechanism. |
|
| |
| RFC 3078 | Microsoft Point-To-Point Encryption (MPPE) Protocol |
| |
| Authors: | G. Pall, G. Zorn. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3078 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointEncryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. |
|
| |
| RFC 3079 | Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) |
| |
| Authors: | G. Zorn. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3079 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
Microsoft Point to Point Encryption (MPPE) is a means of representingPPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 in the Compression Control Protocol.
This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.
MPPE itself (including the protocol used to negotiate its use, the details of the encryption method used and the algorithm used to change session keys during a session) is described in RFC 3078. |
|
| |
| RFC 3080 | The Blocks Extensible Exchange Protocol Core |
| |
| Authors: | M. Rose. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3080 |
|
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP(Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages. |
|
| |
| RFC 3081 | Mapping the BEEP Core onto TCP |
| |
| Authors: | M. Rose. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3081 |
|
This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. |
|
| |
| RFC 3082 | Notification and Subscription for SLP |
| |
| Authors: | J. Kempf, J. Goldschmidt. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3082 |
|
The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears.In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. |
|
| |
| RFC 3083 | Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the BaselinePrivacy Interface (BPI), which provides data privacy for DOCSIS 1.0(Data-Over-Cable Service Interface Specifications) compliant CableModems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.
This memo specifies a MIB module in a manner that is compliant to theSMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards.
CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. |
|
| |
| RFC 3084 | COPS Usage for Policy Provisioning (COPS-PR) |
| |
| Authors: | K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3084 |
|
This document describes the use of the Common Open Policy Service(COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned(QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs.The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data. |
|
| |
| RFC 3085 | URN Namespace for NewsML Resources |
| |
| Authors: | A. Coates, D. Allen, D. Rivers-Moore. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3085 |
|
This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Telecommunications Council (IPTC). |
|
| |
| RFC 3086 | Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification |
| |
| Authors: | K. Nichols, B. Carpenter. |
| Date: | April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3086 |
|
The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select(classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes.
The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, orPDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and
PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service LevelSpecifications at the network edge.
This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to theDiffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. |
|
| |
| RFC 3087 | Control of Service Context using SIP Request-URI |
| |
| Authors: | B. Campbell, R. Sparks. |
| Date: | April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3087 |
|
This memo provides information for the Internet community. It describes a useful way to conceptualize the use of the standard SIP(Session Initiation Protocol) Request-URI (Uniform ResourceIdentifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543.
In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context.In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application. |
|
| |
| RFC 3088 | OpenLDAP Root Service An experimental LDAP referral service |
| |
| Authors: | K. Zeilenga. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3088 |
|
The OpenLDAP Project is operating an experimental LDAP (LightweightDirectory Access Protocol) referral service known as the "OpenLDAPRoot Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain NameSystem location of services resource records). This document describes this service. |
|
| |
| RFC 3089 | A SOCKS-based IPv6/IPv4 Gateway Mechanism |
| |
| Authors: | H. Kitamura. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3089 |
|
This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes.
It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two"terminated" IPv4 and IPv6 connections at the "application layer"(the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished.
Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by theSOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed. |
|
| |
| RFC 3090 | DNS Security Extension Clarification on Zone Status |
| |
|
|
The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. |
|
| |
| RFC 3091 | Pi Digit Generation Protocol |
| |
| Authors: | H. Kennedy. |
| Date: | 1 April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3091 |
|
This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. |
|
| |
| RFC 3092 | Etymology of "Foo" |
| |
| Authors: | D. Eastlake 3rd, C. Manros, E. Raymond. |
| Date: | 1 April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3092 |
|
Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. |
|
| |
| RFC 3093 | Firewall Enhancement Protocol (FEP) |
| |
| Authors: | M. Gaynor, S. Bradner. |
| Date: | 1 April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3093 |
|
Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose theFirewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse aFirewall. Our methodology is to layer any application layerTransmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, sinceHTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, sinceFirewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall. |
|
| |
| RFC 3094 | Tekelec's Transport Adapter Layer Interface |
| |
| Authors: | D. Sprague, R. Benedyk, D. Brendes, J. Keller. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3094 |
|
This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability ApplicationPart), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (SignallingConnection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location. |
|
| |
| RFC 3095 | RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed |
| |
| Authors: | C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. |
| Date: | July 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3759, RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3095 |
|
This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol), UDP/IP, and ESP/IP(Encapsulating Security Payload) headers.
Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common.
This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards trackMobile IPv6 has been completed. |
|
| |
| RFC 3096 | Requirements for robust IP/UDP/RTP header compression |
| |
| Authors: | M. Degermark, Ed.. |
| Date: | July 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3096 |
|
This document contains requirements for robust IP/UDP/RTP (InternetProtocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression)WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. |
|
| |
| RFC 3097 | RSVP Cryptographic Authentication -- Updated Message Type Value |
| |
|
|
This memo resolves a duplication in the assignment of RSVP MessageTypes, by changing the Message Types assigned by RFC 2747 toChallenge and Integrity Response messages. |
|
| |
| RFC 3098 | How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ |
| |
| Authors: | T. Gavin, D. Eastlake 3rd, S. Hambridge. |
| Date: | April 2001 |
| Formats: | txt html json |
| Also: | FYI 0038 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3098 |
|
This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. Some measure of clarity will also be added to the definitions, dangers, and details inherent to Internet Marketing. |
|
| |
| RFC 3099 | Request for Comments Summary RFC Numbers 3000-3099 |
| |
| Authors: | S. Ginoza. |
| Date: | November 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3099 |
|
|
|
