| |
| RFC 3000 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza, L. Shiota. |
| Date: | November 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2900 |
| Obsoleted by: | RFC 3300 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | M. Mealling. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3061 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Harris. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Also: | BCP 0045 |
| Status: | BEST CURRENT PRACTICE |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 3530 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 4721 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | T. Killalea. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Also: | BCP 0046 |
| Status: | BEST CURRENT PRACTICE |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2885, RFC 2886 |
| Obsoleted by: | RFC 3525 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | EXPERIMENTAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoletes: | RFC 1631 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | M. Murata, S. St. Laurent, D. Kohn. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2376 |
| Updates: | RFC 2048 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | G. Montenegro, Ed.. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2344 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 3115 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | T. Showalter. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5228 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | EXPERIMENTAL |
|
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 |
| |
| Authors: | G. Vaudreuil. |
| Date: | December 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1830 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | E. Rosen, A. Viswanathan, R. Callon. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129 |
| Status: | PROPOSED STANDARD |
|
"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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 5036 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 3739 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Obsoleted by: | RFC 4941 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | S. Rozenfeld. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | M. Patrick. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | P. Luthi. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3460 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | M. Mealling. |
| Date: | February 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3001 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | EXPERIMENTAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | P. Traina, D. McPherson, J. Scudder. |
| Date: | February 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1965 |
| Obsoleted by: | RFC 5065 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | C. Huitema. |
| Date: | June 2001 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 3275 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Status: | INFORMATIONAL |
|
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 pdf |
| Status: | PROPOSED STANDARD |
|
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 |
| |
