| |
| RFC 1915 | Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol |
| |
| Authors: | F. Kastenholz. |
| Date: | February 1996 |
| Formats: | txt pdf |
| Also: | BCP 0003 |
| Status: | BEST CURRENT PRACTICE |
|
The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1917 | An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA |
| |
| Authors: | P. Nesser II. |
| Date: | February 1996 |
| Formats: | txt pdf |
| Also: | BCP 0004 |
| Status: | BEST CURRENT PRACTICE |
|
This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to theInternet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment. |
|
| |
| RFC 1918 | Address Allocation for Private Internets |
| |
| Authors: | Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. |
| Date: | February 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1627, RFC 1597 |
| Also: | BCP 0005 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1930 | Guidelines for creation, selection, and registration of an Autonomous System (AS) |
| |
| Authors: | J. Hawkinson, T. Bates. |
| Date: | March 1996 |
| Formats: | txt pdf |
| Also: | BCP 0006 |
| Status: | BEST CURRENT PRACTICE |
|
This memo discusses when it is appropriate to register and utilize anAutonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior GatewayProtocol, now at historical status; see [EGP]), BGP (Border GatewayProtocol, the current de facto standard for inter-AS routing; see[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which theInternet is expected to adopt when BGP becomes obsolete; see [IDRP]).It should be noted that the IDRP equivalent of an AS is the RDI, orRouting Domain Identifier. |
|
| |
| RFC 2008 | Implications of Various Address Allocation Policies for Internet Routing |
| |
| Authors: | Y. Rekhter, T. Li. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Also: | BCP 0007 |
| Status: | BEST CURRENT PRACTICE |
|
The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2014 | IRTF Research Group Guidelines and Procedures |
| |
| Authors: | A. Weinrib, J. Postel. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Also: | BCP 0008 |
| Status: | BEST CURRENT PRACTICE |
|
The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to theInternet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTFResearch Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group(IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined. |
|
| |
| RFC 2026 | The Internet Standards Process -- Revision 3 |
| |
|
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
|
| |
| RFC 2028 | The Organizations Involved in the IETF Standards Process |
| |
|
|
This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF WorkingGroups and the relationship between the IETF and the InternetSociety. |
|
| |
| RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities:
(1) media types,
(2) external body access types,
(3) content-transfer-encodings.
Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2050 | Internet Registry IP Allocation Guidelines |
| |
| Authors: | K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. |
| Date: | November 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1466 |
| Also: | BCP 0012 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes the registry system for the distribution of globally unique Internet address space and registry operations.Particularly this document describes the rules and guidelines governing the distribution of this address space.
This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by theIANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.
This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience.
This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate. |
|
| |
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| |
| Authors: | S. Bradner. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Also: | BCP 0014 |
| Status: | BEST CURRENT PRACTICE |
|
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: |
|
| |
| RFC 2148 | Deployment of the Internet White Pages Service |
| |
| Authors: | H. Alvestrand, P. Jurg. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Also: | BCP 0015 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2182 | Selection and Operation of Secondary DNS Servers |
| |
| Authors: | R. Elz, R. Bush, S. Bradner, M. Patton. |
| Date: | July 1997 |
| Formats: | txt pdf |
| Also: | BCP 0016 |
| Status: | BEST CURRENT PRACTICE |
|
The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. |
|
| |
| RFC 2219 | Use of DNS Aliases for Network Services |
| |
| Authors: | M. Hamilton, R. Wright. |
| Date: | October 1997 |
| Formats: | txt pdf |
| Also: | BCP 0017 |
| Status: | BEST CURRENT PRACTICE |
|
It has become a common practice to use symbolic names (usuallyCNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers,Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP[RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server.
Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.
It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as theServer Location Resource Records (DNS SRV) [RFC-2052] work. |
|
| |
| RFC 2277 | IETF Policy on Character Sets and Languages |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Also: | BCP 0018 |
| Status: | BEST CURRENT PRACTICE |
|
This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2317 | Classless IN-ADDR.ARPA delegation |
| |
| Authors: | H. Eidnes, G. de Groot, P. Vixie. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Also: | BCP 0020 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2350 | Expectations for Computer Security Incident Response |
| |
| Authors: | N. Brownlee, E. Guttman. |
| Date: | June 1998 |
| Formats: | txt pdf |
| Also: | BCP 0021 |
| Status: | BEST CURRENT PRACTICE |
|
The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams(CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities.
CSIRT constituents have a legitimate need and right to fully understand the policies and procedures of 'their' Computer SecurityIncident Response Team. One way to support this understanding is to supply detailed information which users may consider, in the form of a formal template completed by the CSIRT. An outline of such a template and a filled in example are provided. |
|
| |
| RFC 2360 | Guide for Internet Standards Writers |
| |
| Authors: | G. Scott. |
| Date: | June 1998 |
| Formats: | txt pdf |
| Also: | BCP 0022 |
| Status: | BEST CURRENT PRACTICE |
|
This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used withRFC 2223, "Instructions to RFC Authors". |
|
| |
| RFC 2365 | Administratively Scoped IP Multicast |
| |
| Authors: | D. Meyer. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Also: | BCP 0023 |
| Status: | BEST CURRENT PRACTICE |
|
This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2379 | RSVP over ATM Implementation Guidelines |
| |
| Authors: | L. Berger. |
| Date: | August 1998 |
| Formats: | txt pdf |
| Also: | BCP 0024 |
| Status: | BEST CURRENT PRACTICE |
|
This memo presents specific implementation guidelines for runningRSVP over ATM switched virtual circuits (SVCs). The general problem is discussed in [6]. Implementation requirements are discussed in[2]. Integrated Services to ATM service mappings are covered in [3].The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM. |
|
| |
| RFC 2418 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF AreaDirectors. |
|
| |
| RFC 2434 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
| Authors: | T. Narten, H. Alvestrand. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5226 |
| Updated by: | RFC 3692 |
| Status: | BEST CURRENT PRACTICE |
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. |
|
| |
| RFC 2438 | Advancement of MIB specifications on the IETF Standards Track |
| |
| Authors: | M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Also: | BCP 0027 |
| Status: | BEST CURRENT PRACTICE |
|
This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2488 | Enhancing TCP Over Satellite Channels using Standard Mechanisms |
| |
| Authors: | M. Allman, D. Glover, L. Sanchez. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Also: | BCP 0028 |
| Status: | BEST CURRENT PRACTICE |
|
The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards). |
|
| |
| RFC 2489 | Procedure for Defining New DHCP Options |
| |
| Authors: | R. Droms. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2939 |
| Also: | BCP 0029 |
| Status: | BEST CURRENT PRACTICE |
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. |
|
| |
| RFC 2505 | Anti-Spam Recommendations for SMTP MTAs |
| |
| Authors: | G. Lindberg. |
| Date: | February 1999 |
| Formats: | txt pdf |
| Also: | BCP 0030 |
| Status: | BEST CURRENT PRACTICE |
|
This memo gives a number of implementation recommendations for SMTP,[1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*).
The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.
The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to.For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.
A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam. |
|
| |
| RFC 2506 | Media Feature Tag Registration Procedure |
| |
| Authors: | K. Holtman, A. Mutz, T. Hardie. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Also: | BCP 0031 |
| Status: | BEST CURRENT PRACTICE |
|
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2606 | Reserved Top Level DNS Names |
| |
| Authors: | D. Eastlake 3rd, A. Panitz. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Also: | BCP 0032 |
| Status: | BEST CURRENT PRACTICE |
|
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. |
|
| |
| RFC 2611 | URN Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
|
The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". |
|
| |
| RFC 2644 | Changing the Default for Directed Broadcasts in Routers |
| |
| Authors: | D. Senie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Updates: | RFC 1812 |
| Also: | BCP 0034 |
| Status: | BEST CURRENT PRACTICE |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. |
|
| |
| RFC 2717 | Registration Procedures for URL Scheme Names |
| |
| Authors: | R. Petke, I. King. |
| Date: | November 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4395 |
| Also: | BCP 0035 |
| Status: | BEST CURRENT PRACTICE |
|
This document defines the process by which new URL scheme names are registered. |
|
| |
| RFC 2727 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
| Authors: | J. Galvin. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2282 |
| Obsoleted by: | RFC 3777 |
| Status: | BEST CURRENT PRACTICE |
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 2736 | Guidelines for Writers of RTP Payload Format Specifications |
| |
| Authors: | M. Handley, C. Perkins. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Also: | BCP 0036 |
| Status: | BEST CURRENT PRACTICE |
|
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. |
|
| |
| RFC 2780 | IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers |
| |
|
|
This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. |
|
| |
| RFC 2827 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
|
|
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
|
| |
| RFC 2850 | Charter of the Internet Architecture Board (IAB) |
| |
| Authors: | Internet Architecture Board, B. Carpenter, Ed.. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1601 |
| Also: | BCP 0039 |
| Status: | BEST CURRENT PRACTICE |
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC1601. |
|
| |
| RFC 2870 | Root Name Server Operational Requirements |
| |
| Authors: | R. Bush, D. Karrenberg, M. Kosters, R. Plzak. |
| Date: | June 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2010 |
| Also: | BCP 0040 |
| Status: | BEST CURRENT PRACTICE |
|
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. |
|
| |
| RFC 2914 | Congestion Control Principles |
| |
| Authors: | S. Floyd. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Also: | BCP 0041 |
| Status: | BEST CURRENT PRACTICE |
|
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols. |
|
| |
| RFC 2929 | Domain Name System (DNS) IANA Considerations |
| |
| Authors: | D. Eastlake 3rd, E. Brunner-Williams, B. Manning. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Also: | BCP 0042 |
| Status: | BEST CURRENT PRACTICE |
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System(DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. |
|
| |
| RFC 2939 | Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types |
| |
| Authors: | R. Droms. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2489 |
| Also: | BCP 0043 |
| Status: | BEST CURRENT PRACTICE |
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TransmissionControl Protocol/Internet Protocol (TCP/IP) network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message.The data items themselves are also called "options".
DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option.
New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types. |
|
| |
| RFC 2964 | Use of HTTP State Management |
| |
| Authors: | K. Moore, N. Freed. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Also: | BCP 0044 |
| Status: | BEST CURRENT PRACTICE |
|
The mechanisms described in "HTTP State Management Mechanism" (RFC-2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses ofHypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. |
|
| |
| RFC 2978 | IANA Charset Registration Procedures |
| |
| Authors: | N. Freed, J. Postel. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2278 |
| Also: | BCP 0019 |
| Status: | BEST CURRENT PRACTICE |
|
Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046,RFC-2047, RFC-2184) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential.
Note: The charset registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects.In particular, the general applicability and appropriateness of a given registered charset to a particular application is a protocol issue, not a registration issue, and is not dealt with by this registration procedure. |
|
| |
| 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 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 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 3150 | End-to-end Performance Implications of Slow Links |
| |
| Authors: | S. Dawkins, G. Montenegro, M. Kojo, V. Magret. |
| Date: | July 2001 |
| Formats: | txt pdf |
| Also: | BCP 0048 |
| Status: | BEST CURRENT PRACTICE |
|
This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links.
"Very low bit-rate" implies "slower than we would like". This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed.
This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general- purpose mechanism, we point this out and explain why.
This document has some recommendations in common with RFC 2689,"Providing integrated services over low-bitrate links", especially in areas like header compression. This document focuses more on traditional data applications for which "best-effort delivery" is appropriate. |
|
| |
| RFC 3152 | Delegation of IP6.ARPA |
| |
|
|
This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. |
|
| |
| RFC 3155 | End-to-end Performance Implications of Links with Errors |
| |
| Authors: | S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Also: | BCP 0050 |
| Status: | BEST CURRENT PRACTICE |
|
This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. |
|
| |
| RFC 3171 | IANA Guidelines for IPv4 Multicast Address Assignments |
| |
| Authors: | Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Also: | BCP 0051 |
| Status: | BEST CURRENT PRACTICE |
|
This memo provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. |
|
| |
| RFC 3172 | Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") |
| |
| Authors: | G. Huston, Ed.. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Also: | BCP 0052 |
| Status: | BEST CURRENT PRACTICE |
|
This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. The "arpa" domain is used to support a class of infrastructural identifier spaces, providing a distributed database that translates elements of a structured name space derived from a protocol family to service names. The efficient and reliable operation of this DNS space is essential to the integrity of operation of various services within the Internet. The Internet Architecture Board (IAB) has the responsibility, in cooperation with the Internet Corporation forAssigned Names and Numbers (ICANN), to manage the "arpa" domain.This document describes the principles used by the IAB in undertaking this role. |
|
| |
| RFC 3180 | GLOP Addressing in 233/8 |
| |
| Authors: | D. Meyer, P. Lothberg. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2770 |
| Also: | BCP 0053 |
| Status: | BEST CURRENT PRACTICE |
|
This document defines the policy for the use of 233/8 for statically assigned multicast addresses. |
|
| |
| RFC 3184 | IETF Guidelines for Conduct |
| |
| Authors: | S. Harris. |
| Date: | October 2001 |
| Formats: | txt pdf |
| Also: | BCP 0054 |
| Status: | BEST CURRENT PRACTICE |
|
This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The Guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. |
|
| |
| RFC 3205 | On the use of HTTP as a Substrate |
| |
| Authors: | K. Moore. |
| Date: | February 2002 |
| Formats: | txt pdf |
| Also: | BCP 0056 |
| Status: | BEST CURRENT PRACTICE |
|
Recently there has been widespread interest in using HypertextTransfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. |
|
| |
| RFC 3227 | Guidelines for Evidence Collection and Archiving |
| |
| Authors: | D. Brezinski, T. Killalea. |
| Date: | February 2002 |
| Formats: | txt pdf |
| Also: | BCP 0055 |
| Status: | BEST CURRENT PRACTICE |
|
A "security incident" as defined in the "Internet Security Glossary",RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.
If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution. |
|
| |
| RFC 3228 | IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) |
| |
| Authors: | B. Fenner. |
| Date: | February 2002 |
| Formats: | txt pdf |
| Also: | BCP 0057 |
| Status: | BEST CURRENT PRACTICE |
|
This memo requests that the IANA create a registry for fields in theIGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. |
|
| |
| RFC 3233 | Defining the IETF |
| |
| Authors: | P. Hoffman, S. Bradner. |
| Date: | February 2002 |
| Formats: | txt pdf |
| Also: | BCP 0058 |
| Status: | BEST CURRENT PRACTICE |
|
This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many importantIETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. |
|
| |
| RFC 3349 | A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force |
| |
| Authors: | M. Rose. |
| Date: | July 2002 |
| Formats: | txt pdf |
| Also: | BCP 0059 |
| Status: | BEST CURRENT PRACTICE |
|
As a part of their deliverables, working groups of the IETF may develop BEEP profiles. During the development process, it is desirable to assign a transient identifier to each profile. If the profile is subsequently published as an RFC, then a permanent identifier is subsequently assigned by the IANA. |
|
| |
| RFC 3360 | Inappropriate TCP Resets Considered Harmful |
| |
| Authors: | S. Floyd. |
| Date: | August 2002 |
| Formats: | txt pdf |
| Also: | BCP 0060 |
| Status: | BEST CURRENT PRACTICE |
|
This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset.We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure. |
|
| |
| RFC 3365 | Strong Security Requirements for Internet Engineering Task Force Standard Protocols |
| |
| Authors: | J. Schiller. |
| Date: | August 2002 |
| Formats: | txt pdf |
| Also: | BCP 0061 |
| Status: | BEST CURRENT PRACTICE |
|
It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms. This document describes the history and rationale for this doctrine and establishes this doctrine as a best current practice. |
|
| |
| RFC 3366 | Advice to link designers on link Automatic Repeat reQuest (ARQ) |
| |
| Authors: | G. Fairhurst, L. Wood. |
| Date: | August 2002 |
| Formats: | txt pdf |
| Also: | BCP 0062 |
| Status: | BEST CURRENT PRACTICE |
|
This document provides advice to the designers of digital communication equipment and link-layer protocols employing link-layerAutomatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links.
ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used. |
|
| |
| RFC 3372 | Session Initiation Protocol for Telephones (SIP-T): Context and Architectures |
| |
| Authors: | A. Vemuri, J. Peterson. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Also: | BCP 0063 |
| Status: | BEST CURRENT PRACTICE |
|
The popularity of gateways that interwork between the PSTN (PublicSwitched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying). |
|
| |
| RFC 3383 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4520 |
| Status: | BEST CURRENT PRACTICE |
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 3405 | Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures |
| |
| Authors: | M. Mealling. |
| Date: | October 2002 |
| Formats: | txt pdf |
| Also: | BCP 0065 |
| Status: | BEST CURRENT PRACTICE |
|
This document is fifth in a series that is completely specified in"Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3406 | Uniform Resource Names (URN) Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. |
| Date: | October 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2611 |
| Also: | BCP 0066 |
| Status: | BEST CURRENT PRACTICE |
|
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications inRFC 3401 and RFC 3405. The whole rests on the concept of individual"namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. |
|
| |
| RFC 3427 | Change Process for the Session Initiation Protocol (SIP) |
| |
| Authors: | A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Updated by: | RFC 3968, RFC 3969 |
| Also: | BCP 0067 |
| Status: | BEST CURRENT PRACTICE |
|
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. |
|
| |
| RFC 3438 | Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update |
| |
| Authors: | W. Townsley. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Also: | BCP 0068 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes updates to the Internet Assigned NumbersAuthority (IANA) considerations for the Layer Two Tunneling Protocol(L2TP). |
|
| |
| RFC 3449 | TCP Performance Implications of Network Path Asymmetry |
| |
| Authors: | H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Also: | BCP 0069 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use.A summary of the recommendations is provided at the end of the document. |
|
| |
| RFC 3470 | Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols |
| |
| Authors: | S. Hollenbeck, M. Rose, L. Masinter. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Also: | BCP 0070 |
| Status: | BEST CURRENT PRACTICE |
|
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language(SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. |
|
| |
| RFC 3481 | TCP over Second (2.5G) and Third (3G) Generation Wireless Networks |
| |
| Authors: | H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. |
| Date: | February 2003 |
| Formats: | txt pdf |
| Also: | BCP 0071 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. |
|
| |
| RFC 3552 | Guidelines for Writing RFC Text on Security Considerations |
| |
| Authors: | E. Rescorla, B. Korver. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Also: | BCP 0072 |
| Status: | BEST CURRENT PRACTICE |
|
All RFCs are required to have a Security Considerations section.Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good SecurityConsiderations section. |
|
| |
| RFC 3553 | An IETF URN Sub-namespace for Registered Protocol Parameters |
| |
| Authors: | M. Mealling, L. Masinter, T. Hardie, G. Klyne. |
| Date: | June 2003 |
| Formats: | txt pdf |
| Also: | BCP 0073 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer toIETF-defined resources. |
|
| |
| RFC 3584 | Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | R. Frye, D. Levi, S. Routhier, B. Wijnen. |
| Date: | August 2003 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2576 |
| Also: | BCP 0074 |
| Status: | BEST CURRENT PRACTICE |
|
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. |
|
| |
| RFC 3665 | Session Initiation Protocol (SIP) Basic Call Flow Examples |
| |
| Authors: | A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. |
| Date: | December 2003 |
| Formats: | txt pdf |
| Also: | BCP 0075 |
| Status: | BEST CURRENT PRACTICE |
|
This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents andClients, SIP Proxy and Redirect Servers. Scenarios include SIPRegistration and SIP session establishment. Call flow diagrams and message details are shown. |
|
| |
| RFC 3666 | Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows |
| |
| Authors: | A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. |
| Date: | December 2003 |
| Formats: | txt pdf |
| Also: | BCP 0076 |
| Status: | BEST CURRENT PRACTICE |
|
This document contains best current practice examples of SessionInitiation Protocol (SIP) call flows showing interworking with thePublic Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways.Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP.PSTN telephony protocols are illustrated using ISDN (IntegratedServices Digital Network), ISUP (ISDN User Part), and FGB (FeatureGroup B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. |
|
| |
| RFC 3667 | IETF Rights in Contributions |
| |
| Authors: | S. Bradner. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3978 |
| Updates: | RFC 2026 |
| Status: | BEST CURRENT PRACTICE |
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC2026. |
|
| |
| RFC 3668 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies dev | |
