| |
| RFC 1915 | Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 1984 | IAB and IESG Statement on Cryptographic Technology and the Internet |
| |
|
|
The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2008 | Implications of Various Address Allocation Policies for Internet Routing |
| |
|
|
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 json html |
| Also: | BCP 0008 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2014 |
|
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 |
| |
| Authors: | S. Bradner. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1602, RFC 1871 |
| Updated by: | RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282 |
| Also: | BCP 0009 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2026 |
|
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 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| |
|
|
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 json html |
| Also: | BCP 0015 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2148 |
|
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 html json |
| Also: | BCP 0016 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2182 |
|
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 json html |
| Also: | BCP 0017 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2219 |
|
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 |
| |
|
|
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 json html |
| Also: | BCP 0020 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2317 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Also: | BCP 0027 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2438 |
|
This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2488 | Enhancing TCP Over Satellite Channels using Standard Mechanisms |
| |
| Authors: | M. Allman, D. Glover, L. Sanchez. |
| Date: | January 1999 |
| Formats: | txt html json |
| Also: | BCP 0028 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2488 |
|
The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards). |
|
| |
| RFC 2489 | Procedure for Defining New DHCP Options |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. |
|
| |
| RFC 2505 | Anti-Spam Recommendations for SMTP MTAs |
| |
|
|
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 json html |
| Also: | BCP 0031 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2506 |
|
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 |
| |
|
|
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. Faltstrom. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2611 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4395 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2717 |
|
This document defines the process by which new URL scheme names are registered. |
|
| |
| RFC 2727 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 2736 | Guidelines for Writers of RTP Payload Format Specifications |
| |
|
|
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. |
|
| |
| RFC 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) |
| |
|
|
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 json html |
| Obsoletes: | RFC 2010 |
| Obsoleted by: | RFC 7720 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2870 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 5395 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2929 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Also: | BCP 0048 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3150 |
|
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 json html |
| Also: | BCP 0050 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3155 |
|
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 json html |
| Obsoleted by: | RFC 5771 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3171 |
|
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") |
| |
|
|
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 |
| |
|
|
This document defines the policy for the use of 233/8 for statically assigned multicast addresses. |
|
| |
| RFC 3184 | IETF Guidelines for Conduct |
| |
|
|
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 |
| |
|
|
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 html json |
| Also: | BCP 0055 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3227 |
|
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) |
| |
|
|
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 html json |
| Also: | BCP 0058 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3233 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Also: | BCP 0063 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3372 |
|
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 html json |
| Obsoleted by: | RFC 4520 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3383 |
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2611 |
| Obsoleted by: | RFC 8141 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3406 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Also: | BCP 0069 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3449 |
|
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 |
| |
|
|
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 html json |
| Also: | BCP 0071 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3481 |
|
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 |
| |
|
|
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 html json |
| Also: | BCP 0073 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3553 |
|
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 |
| |
|
|
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 html json |
| Also: | BCP 0075 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3665 |
|
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 json html |
| Also: | BCP 0076 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3666 |
|
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 |
| |
|
|
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 developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3677 | IETF ISOC Board of Trustee Appointment Procedures |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | December 2003 |
| Formats: | txt json html |
| Also: | BCP 0077 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3677 |
|
This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment. |
|
| |
| RFC 3681 | Delegation of E.F.F.3.IP6.ARPA |
| |
|
|
This document discusses the need for delegation of theE.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for6bone addresses, and makes specific recommendations for the process needed to accomplish this. |
|
| |
| RFC 3683 | A Practice for Revoking Posting Rights to IETF Mailing Lists |
| |
|
|
All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion.An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. |
|
| |
| RFC 3688 | The IETF XML Registry |
| |
|
|
This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, andResource Description Framework (RDF) Schemas. |
|
| |
| RFC 3692 | Assigning Experimental and Testing Numbers Considered Useful |
| |
|
|
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. |
|
| |
| RFC 3704 | Ingress Filtering for Multihomed Networks |
| |
|
|
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting theInternet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. |
|
| |
| RFC 3725 | Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. |
| Date: | April 2004 |
| Formats: | txt html json |
| Also: | BCP 0085 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3725 |
|
Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. |
|
| |
| RFC 3766 | Determining Strengths For Public Keys Used For Exchanging Symmetric Keys |
| |
|
|
Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage.
While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. |
|
| |
| RFC 3777 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 3785 | Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric |
| |
| Authors: | F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. |
| Date: | May 2004 |
| Formats: | txt json html |
| Also: | BCP 0087 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3785 |
|
This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint BasedRouting of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to performConstraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. |
|
| |
| RFC 3818 | IANA Considerations for the Point-to-Point Protocol (PPP) |
| |
|
|
The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." |
|
| |
| RFC 3819 | Advice for Internet Subnetwork Designers |
| |
| Authors: | P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9599 |
| Also: | BCP 0089 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3819 |
|
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with theInternet architecture and the implications of their design choices on the performance and efficiency of the Internet. |
|
| |
| RFC 3864 | Registration Procedures for Message Header Fields |
| |
|
|
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. |
|
| |
| RFC 3901 | DNS IPv6 Transport Operational Guidelines |
| |
| Authors: | A. Durand, J. Ihren. |
| Date: | September 2004 |
| Formats: | txt json html |
| Also: | BCP 0091 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3901 |
|
This memo provides guidelines and Best Current Practice for operatingDNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. |
|
| |
| RFC 3932 | The IESG and RFC Editor Documents: Procedures |
| |
|
|
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 3933 | A Model for IETF Process Experiments |
| |
| Authors: | J. Klensin, S. Dawkins. |
| Date: | November 2004 |
| Formats: | txt html json |
| Also: | BCP 0093 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3933 |
|
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification.The first mechanism has often proven to be too lightweight, the second too heavyweight.
This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. |
|
| |
| RFC 3934 | Updates to RFC 2418 Regarding the Management of IETF Mailing Lists |
| |
|
|
This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. |
|
| |
| RFC 3935 | A Mission Statement for the IETF |
| |
|
|
This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. |
|
| |
| RFC 3936 | Procedures for Modifying the Resource reSerVation Protocol (RSVP) |
| |
|
|
This memo specifies procedures for modifying the Resource reSerVationProtocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. |
|
| |
| RFC 3967 | Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level |
| |
|
|
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards orIETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. |
|
| |
| RFC 3968 | The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) |
| |
|
|
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. |
|
| |
| RFC 3969 | The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) |
| |
|
|
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS UniformResource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. |
|
| |
| RFC 3978 | IETF Rights in Contributions |
| |
|
|
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 3979, replaces Section 10 of RFC2026. |
|
| |
| RFC 3979 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 4020 | Early IANA Allocation of Standards Track Code Points |
| |
| Authors: | K. Kompella, A. Zinin. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7120 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4020 |
|
This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. |
|
| |
| RFC 4052 | IAB Processes for Management of IETF Liaison Relationships |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | April 2005 |
| Formats: | txt html json |
| Also: | BCP 0102 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4052 |
|
This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and otherStandards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. |
|
| |
| RFC 4053 | Procedures for Handling Liaison Statements to and from the IETF |
| |
| Authors: | S. Trowbridge, S. Bradner, F. Baker. |
| Date: | April 2005 |
| Formats: | txt html json |
| Also: | BCP 0103 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4053 |
|
This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations(SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.
The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. TheIETF is only obligated to respond if there is an agreed liaison relationship, however. |
|
| |
| RFC 4071 | Structure of the IETF Administrative Support Activity (IASA) |
| |
|
|
This document describes the structure of the IETF AdministrativeSupport Activity (IASA) as an activity housed within the InternetSociety (ISOC). It defines the roles and responsibilities of theIETF Administrative Oversight Committee (IAOC), the IETFAdministrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. |
|
| |
| RFC 4084 | Terminology for Describing Internet Connectivity |
| |
|
|
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. |
|
| |
| RFC 4085 | Embedding Globally-Routable Internet Addresses Considered Harmful |
| |
|
|
This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives.This document is intended to clarify best current practices in this regard. |
|
| |
| RFC 4086 | Randomness Requirements for Security |
| |
|
|
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo- security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose.It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. |
|
| |
| RFC 4107 | Guidelines for Cryptographic Key Management |
| |
|
|
The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions.When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. |
|
| |
| RFC 4148 | IP Performance Metrics (IPPM) Metrics Registry |
| |
|
|
This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.
This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.
IANA has been assigned to administer this new registry. |
|
| |
| RFC 4159 | Deprecation of "ip6.int" |
| |
|
|
This document advises of the deprecation of the use of "ip6.int" forStandards Conformant IPv6 implementations. |
|
| |
| RFC 4170 | Tunneling Multiplexed Compressed RTP (TCRTP) |
| |
| Authors: | B. Thompson, T. Koren, D. Wing. |
| Date: | November 2005 |
| Formats: | txt html json |
| Also: | BCP 0110 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4170 |
|
This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-timeTransport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. |
|
| |
| RFC 4181 | Guidelines for Authors and Reviewers of MIB Documents |
| |
|
|
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. |
|
| |
| RFC 4222 | Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance |
| |
|
|
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest PathFirst (OSPF) Version 2 protocol. The methods include processing OSPFHellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. |
|
| |
| RFC 4288 | Media Type Specifications and Registration Procedures |
| |
|
|
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. |
|
| |
| RFC 4289 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. |
|
| |
| RFC 4333 | The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process |
| |
| Authors: | G. Huston, Ed., B. Wijnen, Ed.. |
| Date: | December 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8711 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4333 |
|
This memo outlines the guidelines for selection of members of theIETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. |
|
| |
| RFC 4371 | BCP 101 Update for IPR Trust |
| |
|
|
This document updates BCP 101 to take account of the new IETFIntellectual Property Trust. |
|
| |
| RFC 4384 | BGP Communities for Data Collection |
| |
|
|
BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. |
|
| |
| RFC 4395 | Guidelines and Registration Procedures for New URI Schemes |
| |
|
|
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. |
|
| |
| RFC 4446 | IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) |
| |
|
|
This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in thePseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. |
|
| |
| RFC 4497 | Interworking between the Session Initiation Protocol (SIP) and QSIG |
| |
|
|
This document specifies interworking between the Session InitiationProtocol (SIP) and QSIG within corporate telecommunication networks(also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) withinPrivate Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. |
|
| |
| RFC 4520 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
|
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 4521 | Considerations for Lightweight Directory Access Protocol (LDAP) Extensions |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. |
|
| |
| RFC 4579 | Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents |
| |
|
|
This specification defines conferencing call control features for theSession Initiation Protocol (SIP). This document builds on theConferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference- unaware, conference-aware, and focus UAs. The use of UniformResource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. |
|
| |
| RFC 4608 | Source-Specific Protocol Independent Multicast in 232/8 |
| |
| Authors: | D. Meyer, R. Rockell, G. Shepherd. |
| Date: | August 2006 |
| Formats: | txt html json |
| Also: | BCP 0120 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4608 |
|
IP Multicast group addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. |
|
| |
| RFC 4611 | Multicast Source Discovery Protocol (MSDP) Deployment Scenarios |
| |
| Authors: | M. McBride, J. Meylor, D. Meyer. |
| Date: | August 2006 |
| Formats: | txt html json |
| Also: | BCP 0121 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4611 |
|
This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode(PIM-SM). |
|
| |
| RFC 4632 | Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan |
| |
|
|
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.This document obsoletes the original Classless Inter-domain Routing(CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. |
|
| |
| RFC 4646 | Tags for Identifying Languages |
| |
|
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. |
|
| |
| RFC 4647 | Matching of Language Tags |
| |
|
|
This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag.Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC3066, which replaced RFC 1766. |
|
| |
| RFC 4697 | Observed DNS Resolution Misbehavior |
| |
|
|
This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. |
|
| |
| RFC 4748 | RFC 3978 Update to Recognize the IETF Trust |
| |
|
|
This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of allIETF-related intellectual property rights.
This document does not constrain how the IETF Trust exercises those rights. |
|
| |
| RFC 4774 | Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field |
| |
|
|
There have been a number of proposals for alternate semantics for theExplicit Congestion Notification (ECN) field in the IP header[RFC3168]. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. |
|
| |
| RFC 4775 | Procedures for Protocol Extensions and Variations |
| |
| Authors: | S. Bradner, B. Carpenter, Ed., T. Narten. |
| Date: | December 2006 |
| Formats: | txt html json |
| Also: | BCP 0125 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4775 |
|
This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.
This document is directed principally at other Standards DevelopmentOrganizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. |
|
| |
| RFC 4786 | Operation of Anycast Services |
| |
| Authors: | J. Abley, K. Lindqvist. |
| Date: | December 2006 |
| Formats: | txt json html |
| Also: | BCP 0126 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4786 |
|
As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. |
|
| |
| RFC 4787 | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP |
| |
|
|
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handlingUnicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. |
|
| |
| RFC 4841 | RFC 4181 Update to Recognize the IETF Trust |
| |
|
|
This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. |
|
| |
| RFC 4879 | Clarification of the Third Party Disclosure Procedure in RFC 3979 |
| |
|
|
This document clarifies and updates a single sentence in RFC 3979.Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF ExecutiveDirector notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. |
|
| |
| RFC 4897 | Handling Normative References to Standards-Track Documents |
| |
|
|
The Internet Engineering Task Force (IETF) and Request for Comments(RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best CurrentPractice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to suchReferences. |
|
| |
| RFC 4928 | Avoiding Equal Cost Multipath Treatment in MPLS Networks |
| |
|
|
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over anMPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. |
|
| |
| RFC 4929 | Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures |
| |
| Authors: | L. Andersson, Ed., A. Farrel, Ed.. |
| Date: | June 2007 |
| Formats: | txt html json |
| Also: | BCP 0129 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4929 |
|
This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards DevelopmentOrganizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. |
|
| |
| RFC 4940 | IANA Considerations for OSPF |
| |
|
|
This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. |
|
| |
| RFC 4961 | Symmetric RTP / RTP Control Protocol (RTCP) |
| |
|
|
This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP ControlProtocol (RTCP) sessions, commonly called "symmetric RTP" and"symmetric RTCP". |
|
| |
| RFC 4962 | Guidance for Authentication, Authorization, and Accounting (AAA) Key Management |
| |
|
|
This document provides guidance to designers of Authentication,Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, andAccounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. |
|
| |
| RFC 5033 | Specifying New Congestion Control Algorithms |
| |
|
|
The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. |
|
| |
| RFC 5068 | Email Submission Operations: Access and Accountability Requirements |
| |
| Authors: | C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8314 |
| Also: | BCP 0134 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5068 |
|
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet ServiceProviders. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. |
|
| |
| RFC 5135 | IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) |
| |
|
|
This document specifies requirements for a for a Network AddressTranslator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. AnIP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. |
|
| |
| RFC 5137 | ASCII Escaping of Unicode Characters |
| |
|
|
There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. |
|
| |
| RFC 5226 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all 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 IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. IfIANA is expected to play a role in the management of a namespace,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 namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434. |
|
| |
| RFC 5237 | IANA Allocation Guidelines for the Protocol Field |
| |
|
|
This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. |
|
| |
| RFC 5248 | A Registry for SMTP Enhanced Mail System Status Codes |
| |
|
|
The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes.While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. |
|
| |
| RFC 5249 | Templates for Internet-Drafts Containing MIB Modules |
| |
|
|
This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. |
|
| |
| RFC 5266 | Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) |
| |
| Authors: | V. Devarapalli, P. Eronen. |
| Date: | June 2008 |
| Formats: | txt html json |
| Also: | BCP 0136 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5266 |
|
Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using MobileIPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. |
|
| |
| RFC 5342 | IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters inIETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). |
|
| |
| RFC 5358 | Preventing Use of Recursive Nameservers in Reflector Attacks |
| |
|
|
This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. |
|
| |
| RFC 5359 | Session Initiation Protocol Service Examples |
| |
| Authors: | A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. |
| Date: | October 2008 |
| Formats: | txt html json |
| Also: | BCP 0144 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5359 |
|
This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private BranchExchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. |
|
| |
| RFC 5378 | Rights Contributors Provide to the IETF Trust |
| |
|
|
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 obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replacesSection 10 of RFC 2026. |
|
| |
| RFC 5382 | NAT Behavioral Requirements for TCP |
| |
| Authors: | S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. |
| Date: | October 2008 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0142 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5382 |
|
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. |
|
| |
| RFC 5383 | Deployment Considerations for Lemonade-Compliant Mobile Email |
| |
|
|
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in theIETF lemonade documents. |
|
| |
| RFC 5395 | Domain Name System (DNS) IANA Considerations |
| |
|
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System(DNS) resource record types, CLASSes, operation codes, error codes,DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 5405 | Unicast UDP Usage Guidelines for Application Designers |
| |
| Authors: | L. Eggert, G. Fairhurst. |
| Date: | November 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8085 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5405 |
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.Because congestion control is critical to the stable operation of theInternet, applications and upper-layer protocols that choose to useUDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use ofUDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. |
|
| |
| RFC 5406 | Guidelines for Specifying the Use of IPsec Version 2 |
| |
|
|
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. |
|
| |
| RFC 5407 | Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) |
| |
| Authors: | M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. |
| Date: | December 2008 |
| Formats: | txt json html |
| Also: | BCP 0147 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5407 |
|
This document gives example call flows of race conditions in theSession Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows includeSIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. |
|
| |
| RFC 5508 | NAT Behavioral Requirements for ICMP |
| |
| Authors: | P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0148 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5508 |
|
This document specifies the behavioral properties required of theNetwork Address Translator (NAT) devices in conjunction with theInternet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. |
|
| |
| RFC 5589 | Session Initiation Protocol (SIP) Call Control - Transfer |
| |
| Authors: | R. Sparks, A. Johnston, Ed., D. Petrie. |
| Date: | June 2009 |
| Formats: | txt html json |
| Also: | BCP 0149 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5589 |
|
This document describes providing Call Transfer capabilities in theSession Initiation Protocol (SIP). SIP extensions such as REFER andReplaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. |
|
| |
| RFC 5597 | Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol |
| |
|
|
This document defines a set of requirements for NATs handling theDatagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements forNATs, which have already been published by the IETF. Ensuring thatNATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. |
|
| |
| RFC 5615 | H.248/MEGACO Registration Procedures |
| |
|
|
This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. |
|
| |
| RFC 5625 | DNS Proxy Implementation Guidelines |
| |
|
|
This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. |
|
| |
| RFC 5633 | Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers |
| |
|
|
This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. |
|
| |
| RFC 5646 | Tags for Identifying Languages |
| |
|
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. |
|
| |
| RFC 5657 | Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard |
| |
|
|
Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. |
|
| |
| RFC 5680 | The Nominating Committee Process: Open Disclosure of Willing Nominees |
| |
|
|
This document updates RFC 3777, Section 3, Bullet 6 to allow aNominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. |
|
| |
| RFC 5727 | Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area |
| |
|
|
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC3427. |
|
| |
| RFC 5735 | Special Use IPv4 Addresses |
| |
|
|
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by theInternet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the RegionalInternet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional InternetRegistries. It also does not address allocations or assignments ofIPv6 addresses or autonomous system numbers. |
|
| |
| RFC 5742 | IESG Procedures for Handling of Independent and IRTF Stream Submissions |
| |
|
|
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the IndependentSubmission and IRTF streams.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 5771 | IANA Guidelines for IPv4 Multicast Address Assignments |
| |
|
|
This document provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. It obsoletesRFC 3171 and RFC 3138 and updates RFC 2780. |
|
| |
| RFC 5774 | Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition |
| |
|
|
This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. |
|
| |
| RFC 5855 | Nameservers for IPv4 and IPv6 Reverse Zones |
| |
|
|
This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). |
|
| |
| RFC 6056 | Recommendations for Transport-Protocol Port Randomization |
| |
|
|
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the TransmissionControl Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, DestinationAddress, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such asTCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). |
|
| |
| RFC 6158 | RADIUS Design Guidelines |
| |
|
|
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). |
|
| |
| RFC 6177 | IPv6 Address Assignment to End Sites |
| |
|
|
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005.This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177.Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
This document obsoletes RFC 3177. |
|
| |
| RFC 6191 | Reducing the TIME-WAIT State Using TCP Timestamps |
| |
|
|
This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. |
|
| |
| RFC 6195 | Domain Name System (DNS) IANA Considerations |
| |
|
|
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 6280 | An Architecture for Location and Location Privacy in Internet Applications |
| |
|
|
Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. |
|
| |
| RFC 6291 | Guidelines for the Use of the "OAM" Acronym in the IETF |
| |
| Authors: | L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield. |
| Date: | June 2011 |
| Formats: | txt html json |
| Also: | BCP 0161 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6291 |
|
At first glance, the acronym "OAM" seems to be well-known and well- understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.
This document provides a definition of the acronym "OAM" (Operations,Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. |
|
| |
| RFC 6302 | Logging Recommendations for Internet-Facing Servers |
| |
| Authors: | A. Durand, I. Gashinsky, D. Lee, S. Sheppard. |
| Date: | June 2011 |
| Formats: | txt json html |
| Also: | BCP 0162 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6302 |
|
In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. |
|
| |
| RFC 6303 | Locally Served DNS Zones |
| |
|
|
Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise.RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC1918 address space and other well-known zones with similar characteristics. |
|
| |
| RFC 6328 | IANA Considerations for Network Layer Protocol Identifiers |
| |
|
|
Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization /International Electrotechnical Commission) Network Layer ProtocolIdentifier (NLPID). This document provides NLPID IANA considerations. |
|
| |
| RFC 6335 | Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry |
| |
|
|
This document defines the procedures that the Internet AssignedNumbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol PortNumber registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.
This document updates IANA's procedures by obsoleting the previousUDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the DatagramCongestion Control Protocol (DCCP), and the Stream ControlTransmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. |
|
| |
| RFC 6365 | Terminology Used in Internationalization in the IETF |
| |
|
|
This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. |
|
| |
| RFC 6377 | DomainKeys Identified Mail (DKIM) and Mailing Lists |
| |
|
|
DomainKeys Identified Mail (DKIM) allows an ADministrative ManagementDomain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers(MLMs). |
|
| |
| RFC 6382 | Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services |
| |
| Authors: | D. McPherson, R. Donnelly, F. Scalzo. |
| Date: | October 2011 |
| Formats: | txt html json |
| Also: | BCP 0169 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6382 |
|
This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. |
|
| |
| RFC 6390 | Guidelines for Considering New Performance Metric Development |
| |
|
|
This document describes a framework and a process for developingPerformance Metrics of protocols and applications transported overIETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. |
|
| |
| RFC 6398 | IP Router Alert Considerations and Usage |
| |
|
|
The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. TheResource reSerVation Protocol (RSVP), Pragmatic General Multicast(PGM), the Internet Group Management Protocol (IGMP), MulticastListener Discovery (MLD), Multicast Router Discovery (MRD), andGeneral Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the currentIP Router Alert Option, thereby updating RFC 2113 and RFC 2711.Specifically, it provides recommendations against using the RouterAlert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines forRouter Alert implementation on routers. |
|
| |
| RFC 6410 | Reducing the Standards Track to Two Maturity Levels |
| |
|
|
This document updates the Internet Engineering Task Force (IETF)Standards Process defined in RFC 2026. Primarily, it reduces theStandards Process from three Standards Track maturity levels to two. |
|
| |
| RFC 6441 | Time to Remove Filters for Previously Unallocated IPv4 /8s |
| |
|
|
It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.
This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. |
|
| |
| RFC 6472 | Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP |
| |
| Authors: | W. Kumari, K. Sriram. |
| Date: | December 2011 |
| Formats: | txt json html |
| Also: | BCP 0172 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6472 |
|
This document recommends against the use of the AS_SET andAS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. |
|
| |
| RFC 6484 | Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Kent, D. Kong, K. Seo, R. Watro. |
| Date: | February 2012 |
| Formats: | txt html json |
| Also: | BCP 0173 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6484 |
|
This document describes the certificate policy for a Public KeyInfrastructure (PKI) used to support attestations about InternetNumber Resource (INR) holdings. Each organization that distributesIP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. |
|
| |
| RFC 6489 | Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | G. Huston, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Also: | BCP 0174 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6489 |
|
This document describes how a Certification Authority (CA) in theResource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. |
|
| |
| RFC 6540 | IPv6 Support Required for All IP-Capable Nodes |
| |
| Authors: | W. George, C. Donley, C. Liljenstolpe, L. Howard. |
| Date: | April 2012 |
| Formats: | txt json html |
| Also: | BCP 0177 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6540 |
|
Given the global lack of available IPv4 space, and limitations inIPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, orIPv4-only, depending on context and application. |
|
| |
| RFC 6557 | Procedures for Maintaining the Time Zone Database |
| |
|
|
Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone(TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. |
|
| |
| RFC 6576 | IP Performance Metrics (IPPM) Standard Advancement Testing |
| |
| Authors: | R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. |
| Date: | March 2012 |
| Formats: | txt html json |
| Also: | BCP 0176 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6576 |
|
This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along theStandards Track. Results from different implementations of metricRFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is anInternet Best Current Practice. |
|
| |
| RFC 6598 | IANA-Reserved IPv4 Prefix for Shared Address Space |
| |
| Authors: | J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 5735 |
| Also: | BCP 0153 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6598 |
|
This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks.However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.
This document details the allocation of an additional special-useIPv4 address block and updates RFC 5735. |
|
| |
| RFC 6648 | Deprecating the "X-" Prefix and Similar Constructs in Application Protocols |
| |
| Authors: | P. Saint-Andre, D. Crocker, M. Nottingham. |
| Date: | June 2012 |
| Formats: | txt html json |
| Also: | BCP 0178 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6648 |
|
Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual(as opposed to numerical) names in application protocols. |
|
| |
| RFC 6649 | Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos |
| |
|
|
The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the NationalInstitute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average.DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms inKerberos. Because RFC 1510 (obsoleted by RFC 4120) supports onlyDES, this document recommends the reclassification of RFC 1510 asHistoric. |
|
| |
| RFC 6838 | Media Type Specifications and Registration Procedures |
| |
|
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
|
| |
| RFC 6853 | DHCPv6 Redundancy Deployment Considerations |
| |
| Authors: | J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. |
| Date: | February 2013 |
| Formats: | txt html json |
| Also: | BCP 0180 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6853 |
|
This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services. |
|
| |
| RFC 6859 | Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership |
| |
|
|
RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative OversightCommittee (IAOC) was formed; that body is not covered by RFC 3777.There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of theIAB, the IESG, and the IAOC. |
|
| |
| RFC 6881 | Best Current Practice for Communications Services in Support of Emergency Calling |
| |
|
|
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. |
|
| |
| RFC 6888 | Common Requirements for Carrier-Grade NATs (CGNs) |
| |
| Authors: | S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida. |
| Date: | April 2013 |
| Formats: | txt json html |
| Updates: | RFC 4787 |
| Also: | BCP 0127 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6888 |
|
This document defines common requirements for Carrier-Grade NATs(CGNs). It updates RFC 4787. |
|
| |
| RFC 6890 | Special-Purpose IP Address Registries |
| |
|
|
This memo reiterates the assignment of an IPv4 address block(192.0.0.0/24) to IANA. It also instructs IANA to restructure itsIPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special- purpose address blocks, maintaining a common set of information regarding each address block.
This memo obsoletes RFCs 4773, 5156, 5735, and 5736. |
|
| |
| RFC 6895 | Domain Name System (DNS) IANA Considerations |
| |
|
|
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. |
|
| |
| RFC 6916 | Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Gagliano, S. Kent, S. Turner. |
| Date: | April 2013 |
| Formats: | txt html json |
| Also: | BCP 0182 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6916 |
|
This document specifies the process that Certification Authorities(CAs) and Relying Parties (RPs) participating in the Resource PublicKey Infrastructure (RPKI) will need to follow to transition to a new(and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years.Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration(parent migrates before children). |
|
| |
| RFC 6963 | A Uniform Resource Name (URN) Namespace for Examples |
| |
|
|
This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation. |
|
| |
| RFC 6996 | Autonomous System (AS) Reservation for Private Use |
| |
|
|
This document describes the reservation of Autonomous System Numbers(ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. |
|
| |
| RFC 7013 | Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements |
| |
| Authors: | B. Trammell, B. Claise. |
| Date: | September 2013 |
| Formats: | txt html json |
| Also: | BCP 0184 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7013 |
|
This document provides guidelines for how to write definitions of newInformation Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIXInformation Element registry, and provides guidelines for expert reviewers to evaluate new registrations. |
|
| |
| RFC 7042 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. |
|
| |
| RFC 7100 | Retirement of the "Internet Official Protocol Standards" Summary Document |
| |
|
|
This document updates RFC 2026 to no longer use STD 1 as a summary of"Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status. |
|
| |
| RFC 7115 | Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) |
| |
|
|
Deployment of BGP origin validation that is based on the ResourcePublic Key Infrastructure (RPKI) has many operational considerations.This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. |
|
| |
| RFC 7120 | Early IANA Allocation of Standards Track Code Points |
| |
|
|
This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFCRequired", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.
This document obsoletes RFC 4020. |
|
| |
| RFC 7126 | Recommendations on Filtering of IPv4 Packets Containing IPv4 Options |
| |
| Authors: | F. Gont, R. Atkinson, C. Pignataro. |
| Date: | February 2014 |
| Formats: | txt json html |
| Also: | BCP 0186 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7126 |
|
This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. |
|
| |
| RFC 7127 | Characterization of Proposed Standards |
| |
|
|
RFC 2026 describes the review performed by the Internet EngineeringSteering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards. |
|
| |
| RFC 7141 | Byte and Packet Congestion Notification |
| |
|
|
This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre-Congestion Notification (PCN), and newer schemes such as CoDel(Controlled Delay) and PIE (Proportional Integral controllerEnhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. |
|
| |
| RFC 7154 | IETF Guidelines for Conduct |
| |
|
|
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.
This document is an updated version of the guidelines for conduct originally published in RFC 3184. |
|
| |
| RFC 7227 | Guidelines for Creating New DHCPv6 Options |
| |
| Authors: | D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updates: | RFC 3315 |
| Also: | BCP 0187 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7227 |
|
This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315. |
|
| |
| RFC 7258 | Pervasive Monitoring Is an Attack |
| |
| Authors: | S. Farrell, H. Tschofenig. |
| Date: | May 2014 |
| Formats: | txt html json |
| Also: | BCP 0188 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7258 |
|
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. |
|
| |
| RFC 7279 | An Acceptable Use Policy for New ICMP Types and Codes |
| |
|
|
In this document we provide a basic description of ICMP's role in theIP stack and some guidelines for future use.
This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not. |
|
| |
| RFC 7300 | Reservation of Last Autonomous System (AS) Numbers |
| |
|
|
This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as"Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930. |
|
| |
| RFC 7319 | IANA Considerations for Connectivity Fault Management (CFM) Code Points |
| |
|
|
IEEE 802.1 has specified Connectivity Fault Management (CFM)Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks. |
|
| |
| RFC 7320 | URI Design and Ownership |
| |
|
|
Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. |
|
| |
| RFC 7382 | Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) |
| |
| Authors: | S. Kent, D. Kong, K. Seo. |
| Date: | April 2015 |
| Formats: | txt html json |
| Also: | BCP 0173 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7382 |
|
This document contains a template to be used for creating aCertification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. |
|
| |
| RFC 7423 | Diameter Applications Design Guidelines |
| |
| Authors: | L. Morand, Ed., V. Fajardo, H. Tschofenig. |
| Date: | November 2014 |
| Formats: | txt html json |
| Also: | BCP 0193 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7423 |
|
The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions. |
|
| |
| RFC 7437 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 7454 | BGP Operations and Security |
| |
| Authors: | J. Durand, I. Pepelnjak, G. Doering. |
| Date: | February 2015 |
| Formats: | txt html json |
| Also: | BCP 0194 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7454 |
|
The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.
This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System(AS) path filtering, route flap dampening, and BGP community scrubbing. |
|
| |
| RFC 7475 | Increasing the Number of Area Directors in an IETF Area |
| |
|
|
This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25). |
|
| |
| RFC 7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS.The recommendations are applicable to the majority of use cases. |
|
| |
| RFC 7526 | Deprecating the Anycast Prefix for 6to4 Relay Routers |
| |
|
|
Experience with the 6to4 transition mechanism defined in RFC 3056("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in theInternet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. |
|
| |
| RFC 7567 | IETF Recommendations Regarding Active Queue Management |
| |
|
|
This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309. |
|
| |
| RFC 7595 | Guidelines and Registration Procedures for URI Schemes |
| |
|
|
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of UniformResource Identifier (URI) schemes. It obsoletes RFC 4395. |
|
| |
| RFC 7605 | Recommendations on Using Assigned Transport Port Numbers |
| |
|
|
This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.It provides guidelines for designers regarding how to interact with the IANA processes defined in RFC 6335, thus serving to complement(but not update) that document. |
|
| |
| RFC 7608 | IPv6 Prefix Length Recommendation for Forwarding |
| |
| Authors: | M. Boucadair, A. Petrescu, F. Baker. |
| Date: | July 2015 |
| Formats: | txt json html |
| Also: | BCP 0198 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7608 |
|
IPv6 prefix length, as in IPv4, is a parameter conveyed and used inIPv6 routing and forwarding processes in accordance with theClassless Inter-domain Routing (CIDR) architecture. The length of anIPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. |
|
| |
| RFC 7610 | DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers |
| |
| Authors: | F. Gont, W. Liu, G. Van de Velde. |
| Date: | August 2015 |
| Formats: | txt json html |
| Also: | BCP 0199 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7610 |
|
This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based onDHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield. |
|
| |
| RFC 7691 | Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members |
| |
|
|
BCP 101 defines the start and end dates for the terms of IETFAdministrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct theIAOC to establish more practical start and end dates for terms ofIAOC members. |
|
| |
| RFC 7696 | Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms |
| |
|
|
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. |
|
| |
| RFC 7720 | DNS Root Name Service Protocol and Deployment Requirements |
| |
|
|
The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope. |
|
| |
| RFC 7772 | Reducing Energy Consumption of Router Advertisements |
| |
| Authors: | A. Yourtchenko, L. Colitti. |
| Date: | February 2016 |
| Formats: | txt html json |
| Also: | BCP 0202 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7772 |
|
Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. |
|
| |
| RFC 7776 | IETF Anti-Harassment Procedures |
| |
|
|
IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.
This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. |
|
| |
| RFC 7793 | Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry |
| |
|
|
RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."
This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure. |
|
| |
| RFC 7803 | Changing the Registration Policy for the NETCONF Capability URNs Registry |
| |
|
|
The registration policy for the "Network Configuration Protocol(NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to StandardsTrack RFCs. |
|
| |
| RFC 7857 | Updates to Network Address Translation (NAT) Behavioral Requirements |
| |
|
|
This document clarifies and updates several requirements of RFCs4787, 5382, and 5508 based on operational and development experience.The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).
This document updates RFCs 4787, 5382, and 5508. |
|
| |
| RFC 7926 | Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks |
| |
| Authors: | A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang. |
| Date: | July 2016 |
| Formats: | txt html json |
| Also: | BCP 0206 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7926 |
|
In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity.This subset of TE information is called TE reachability information.
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. |
|
| |
| RFC 7934 | Host Address Availability Recommendations |
| |
| Authors: | L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. |
| Date: | July 2016 |
| Formats: | txt json html |
| Also: | BCP 0204 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7934 |
|
This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so. |
|
| |
| RFC 7942 | Improving Awareness of Running Code: The Implementation Status Section |
| |
|
|
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. |
|
| |
| RFC 7957 | DISPATCH-Style Working Groups and the SIP Change Process |
| |
|
|
RFC 5727 defined several processes for the former Real-timeApplications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. |
|
| |
| RFC 8027 | DNSSEC Roadblock Avoidance |
| |
| Authors: | W. Hardaker, O. Gudmundsson, S. Krishnaswamy. |
| Date: | November 2016 |
| Formats: | txt json html |
| Also: | BCP 0207 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8027 |
|
This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. |
|
| |
| RFC 8067 | Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level |
| |
|
|
RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents. |
|
| |
| RFC 8084 | Network Transport Circuit Breakers |
| |
|
|
This document explains what is meant by the term "network transportCircuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet. |
|
| |
| RFC 8085 | UDP Usage Guidelines |
| |
|
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ExplicitCongestion Notification (ECN), Differentiated Services Code Points(DSCPs), and ports.
Because congestion control is critical to the stable operation of theInternet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.
Some guidance is also applicable to the design of other protocols(e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.
This document obsoletes RFC 5405 and adds guidelines for multicastUDP usage. |
|
| |
| RFC 8109 | Initializing a DNS Resolver with Priming Queries |
| |
| Authors: | P. Koch, M. Larson, P. Hoffman. |
| Date: | March 2017 |
| Formats: | txt json html |
| Also: | BCP 0209 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8109 |
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. |
|
| |
| RFC 8126 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226. |
|
| |
| RFC 8174 | Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words |
| |
|
|
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. |
|
| |
| RFC 8179 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.This document also obsoletes RFCs 3979 and 4879. |
|
| |
| RFC 8180 | Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration |
| |
| Authors: | X. Vilajosana, Ed., K. Pister, T. Watteyne. |
| Date: | May 2017 |
| Formats: | txt html json |
| Also: | BCP 0210 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8180 |
|
This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH providesIPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices. |
|
| |
| RFC 8190 | Updates to the Special-Purpose IP Address Registries |
| |
|
|
This memo updates the IANA IPv4 and IPv6 Special-Purpose AddressRegistries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890. |
|
| |
| RFC 8207 | BGPsec Operational Considerations |
| |
|
|
Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed. |
|
| |
| RFC 8252 | OAuth 2.0 for Native Apps |
| |
|
|
OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. |
|
| |
| RFC 8313 | Use of Multicast across Inter-domain Peering Points |
| |
| Authors: | P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Also: | BCP 0213 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8313 |
|
This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process. |
|
| |
| RFC 8318 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 8327 | Mitigating the Negative Impact of Maintenance through BGP Session Culling |
| |
| Authors: | W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. |
| Date: | March 2018 |
| Formats: | txt html json |
| Also: | BCP 0214 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8327 |
|
This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence. |
|
| |
| RFC 8340 | YANG Tree Diagrams |
| |
|
|
This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. |
|
| |
| RFC 8407 | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol(NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087. |
|
| |
| RFC 8421 | Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) |
| |
| Authors: | P. Martinsen, T. Reddy, P. Patil. |
| Date: | July 2018 |
| Formats: | txt html json |
| Also: | BCP 0217 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8421 |
|
This document provides guidelines on how to make InteractiveConnectivity Establishment (ICE) conclude faster in multihomed andIPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245). |
|
| |
| RFC 8429 | Deprecate Triple-DES (3DES) and RC4 in Kerberos |
| |
|
|
The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved toHistoric status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types. |
|
| |
| RFC 8499 | DNS Terminology |
| |
|
|
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in theDNS in a single document.
This document obsoletes RFC 7719 and updates RFC 2308. |
|
| |
| RFC 8504 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 6434, and in turn RFC 4294. |
|
| |
| RFC 8521 | Registration Data Access Protocol (RDAP) Object Tagging |
| |
|
|
The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries. |
|
| |
| RFC 8552 | Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves |
| |
|
|
Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the"Underscored and Globally Scoped DNS Node Names" registry with IANA.The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. |
|
| |
| RFC 8553 | DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names |
| |
| Authors: | D. Crocker. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 2782, RFC 3263, RFC 3529, RFC 3620, RFC 3832, RFC 3887, RFC 3958, RFC 4120, RFC 4227, RFC 4386, RFC 4387, RFC 4976, RFC 5026, RFC 5328, RFC 5389, RFC 5415, RFC 5518, RFC 5555, RFC 5617, RFC 5679, RFC 5766, RFC 5780, RFC 5804, RFC 5864, RFC 5928, RFC 6120, RFC 6186, RFC 6376, RFC 6733, RFC 6763, RFC 7208, RFC 7489, RFC 8145 |
| Also: | BCP 0222 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8553 |
|
Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace.A registry for these names has now been defined by RFC 8552.However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. |
|
| |
| RFC 8633 | Network Time Protocol Best Current Practices |
| |
| Authors: | D. Reilly, H. Stenn, D. Sibold. |
| Date: | July 2019 |
| Formats: | txt json html |
| Also: | BCP 0223 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8633 |
|
The Network Time Protocol (NTP) is one of the oldest protocols on theInternet and has been widely used since its initial publication.This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905. |
|
| |
| RFC 8634 | BGPsec Router Certificate Rollover |
| |
| Authors: | B. Weis, R. Gagliano, K. Patel. |
| Date: | August 2019 |
| Formats: | txt html json |
| Also: | BCP 0224 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8634 |
|
Certification Authorities (CAs) within the Resource Public KeyInfrastructure (RPKI) manage BGPsec router certificates as well asRPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost. |
|
| |
| RFC 8704 | Enhanced Feasible-Path Unicast Reverse Path Forwarding |
| |
|
|
This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38).Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704).However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. |
|
| |
| RFC 8711 | Structure of the IETF Administrative Support Activity, Version 2.0 |
| |
|
|
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe theIETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLCBoard (IETF LLC Board), the IETF Executive Director, and the InternetSociety in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.
This document obsoletes RFC 4071, RFC 4333, and RFC 7691. |
|
| |
| RFC 8713 | IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC(IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF AdministrativeSupport Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.
This document obsoletes RFC 7437 and RFC 8318. |
|
| |
| RFC 8714 | Update to the Process for Selection of Trustees for the IETF Trust |
| |
|
|
This memo updates the process for selection of Trustees for the IETFTrust. Previously, the IETF Administrative Oversight Committee(IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETFAdministrative Support Activity (IASA). This memo specifies that theTrustees shall be selected separately.
This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today. |
|
| |
| RFC 8716 | Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC |
| |
|
|
The IETF Anti-Harassment Procedures are described in RFC 7776.
The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.
RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates. |
|
| |
| RFC 8717 | IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology |
| |
|
|
In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes. |
|
| |
| RFC 8718 | IETF Plenary Meeting Venue Selection Process |
| |
|
|
The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process. |
|
| |
| RFC 8719 | High-Level Guidance for the Meeting Policy of the IETF |
| |
|
|
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy. |
|
| |
| RFC 8725 | JSON Web Token Best Current Practices |
| |
|
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. ThisBest Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. |
|
| |
| RFC 8758 | Deprecating RC4 in Secure Shell (SSH) |
| |
|
|
This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status. |
|
| |
| RFC 8788 | Eligibility for the 2020-2021 Nominating Committee |
| |
|
|
The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in- person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future. |
|
| |
| RFC 8789 | IETF Stream Documents Require IETF Rough Consensus |
| |
|
|
This document requires that the IETF never publish any IETF StreamRFCs without IETF rough consensus. This updates RFC 2026. |
|
| |
| RFC 8815 | Deprecating Any-Source Multicast (ASM) for Interdomain Multicast |
| |
| Authors: | M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert. |
| Date: | August 2020 |
| Formats: | txt xml pdf json html |
| Also: | BCP 0229 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8815 |
|
This document recommends deprecation of the use of Any-SourceMulticast (ASM) for interdomain multicast. It recommends the use ofSource-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM). |
|
| |
| RFC 8820 | URI Design and Ownership |
| |
|
|
Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.
This document provides guidance on the specification of URI substructure in standards.
This document obsoletes RFC 7320 and updates RFC 3986. |
|
| |
| RFC 8862 | Best Practices for Securing RTP Media Signaled with SIP |
| |
|
|
Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. |
|
| |
| RFC 8900 | IP Fragmentation Considered Fragile |
| |
| Authors: | R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont. |
| Date: | September 2020 |
| Formats: | txt html pdf json xml |
| Also: | BCP 0230 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8900 |
|
This document describes IP fragmentation and explains how it introduces fragility to Internet communication.
This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. |
|
| |
| RFC 8906 | A Common Operational Problem in DNS Servers: Failure to Communicate |
| |
|
|
The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.
This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.
The document does not look at the DNS data itself, just the structure of the responses. |
|
| |
| RFC 8932 | Recommendations for DNS Privacy Service Operators |
| |
| Authors: | S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin. |
| Date: | October 2020 |
| Formats: | txt json html pdf xml |
| Also: | BCP 0232 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8932 |
|
This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.
This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNSSecurity Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841. |
|
| |
| RFC 8958 | Updated Registration Rules for URI.ARPA |
| |
|
|
This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone. |
|
| |
| RFC 8961 | Requirements for Time-Based Loss Detection |
| |
|
|
Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet"lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high- level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. |
|
| |
| RFC 8996 | Deprecating TLS 1.0 and TLS 1.1 |
| |
| Authors: | K. Moriarty, S. Farrell. |
| Date: | March 2021 |
| Formats: | txt html json pdf xml |
| Obsoletes: | RFC 5469, RFC 7507 |
| Updates: | RFC 3261, RFC 3329, RFC 3436, RFC 3470, RFC 3501, RFC 3552, RFC 3568, RFC 3656, RFC 3749, RFC 3767, RFC 3856, RFC 3871, RFC 3887, RFC 3903, RFC 3943, RFC 3983, RFC 4097, RFC 4111, RFC 4162, RFC 4168, RFC 4217, RFC 4235, RFC 4261, RFC 4279, RFC 4497, RFC 4513, RFC 4531, RFC 4540, RFC 4582, RFC 4616, RFC 4642, RFC 4680, RFC 4681, RFC 4712, RFC 4732, RFC 4743, RFC 4744, RFC 4785, RFC 4791, RFC 4823, RFC 4851, RFC 4964, RFC 4975, RFC 4976, RFC 4992, RFC 5018, RFC 5019, RFC 5023, RFC 5024, RFC 5049, RFC 5054, RFC 5091, RFC 5158, RFC 5216, RFC 5238, RFC 5263, RFC 5281, RFC 5364, RFC 5415, RFC 5422, RFC 5456, RFC 5734, RFC 5878, RFC 5953, RFC 6012, RFC 6042, RFC 6083, RFC 6084, RFC 6176, RFC 6347, RFC 6353, RFC 6367, RFC 6460, RFC 6614, RFC 6739, RFC 6749, RFC 6750, RFC 7030, RFC 7465, RFC 7525, RFC 7562, RFC 7568, RFC 8261, RFC 8422 |
| Also: | BCP 0195 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8996 |
|
This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions.TLS version 1.2 became the recommended version for IETF protocols in2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions.Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.
This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC4347) but not DTLS version 1.2, and there is no DTLS version 1.1.
This document updates many RFCs that normatively refer to TLS version1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. |
|
| |
| RFC 9096 | Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events |
| |
|
|
This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084. |
|
| |
| RFC 9137 | Considerations for Cancellation of IETF Meetings |
| |
|
|
The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet. However, various events can make a planned in-person meeting infeasible. This document provides criteria to aid the IETF Administration LLC (IETF LLC), the InternetEngineering Steering Group (IESG), and the Chair of the InternetResearch Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting. |
|
| |
| RFC 9205 | Building Protocols with HTTP |
| |
|
|
Applications often use HTTP as a substrate to create HTTP-based APIs.This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols usingHTTP for deployment on the Internet but might be applicable in other situations.
This document obsoletes RFC 3205. |
|
| |
| RFC 9210 | DNS Transport over TCP - Operational Requirements |
| |
|
|
This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried overTCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. |
|
| |
| RFC 9245 | IETF Discussion List Charter |
| |
|
|
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.
This document obsoletes RFC 3005 and updates RFC 3683. |
|
| |
| RFC 9276 | Guidance for NSEC3 Parameter Settings |
| |
|
|
NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters. |
|
| |
| RFC 9281 | Entities Involved in the IETF Standards Process |
| |
|
|
This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process.
The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. |
|
| |
| RFC 9282 | Responsibility Change for the RFC Series |
| |
|
|
In RFC 9280, responsibility for the RFC Series moved to the RFCSeries Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted. |
|
| |
| RFC 9283 | IAB Charter Update for RFC Editor Model |
| |
|
|
This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280). |
|
| |
| RFC 9319 | The Use of maxLength in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison. |
| Date: | October 2022 |
| Formats: | txt json html xml pdf |
| Also: | BCP 0185 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 9319 |
|
This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those inRFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-basedRoute Origin Validation (RPKI-ROV) in the context of destination- based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted. |
|
| |
| RFC 9325 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.
RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. |
|
| |
| RFC 9364 | DNS Security Extensions (DNSSEC) |
| |
|
|
This document describes the DNS Security Extensions (commonly called"DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects ofDNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication ofDNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. |
|
| |
| RFC 9389 | Nominating Committee Eligibility |
| |
|
|
The IETF Nominating Committee (NomCom) appoints candidates to severalIETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, theIETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletesRFCs 8788 and 8989. |
|
| |
| RFC 9416 | Security Considerations for Transient Numeric Identifiers Employed in Network Protocols |
| |
|
|
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations. |
|
| |
| RFC 9455 | Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes |
| |
| Authors: | Z. Yan, R. Bush, G. Geng, T. de Kock, J. Yao. |
| Date: | August 2023 |
| Formats: | txt json html xml pdf |
| Also: | BCP 0238 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 9455 |
|
When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. |
|
| |
| RFC 9499 | DNS Terminology |
| |
|
|
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
This document updates RFC 2308 by clarifying the definitions of"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. |
|
| |
| RFC 9501 | Open Participation Principle regarding Remote Registration Fee |
| |
|
|
This document outlines a principle for open participation that extends the open process principle defined in RFC 3935 by stating that there must be a free option for online participation to IETF meetings and, if possible, related IETF-hosted events. |
|
| |
| RFC 9542 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANAOrganizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. |
|
| |
| RFC 9599 | Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP |
| |
|
|
The purpose of this document is to guide the design of congestion notification in any lower-layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower-layer protocols into IP. Then, theIP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Specifications that follow these guidelines, whether produced by the IETF or other standards bodies, should assure interworking among IP-layer and lower-layer congestion notification mechanisms. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ExplicitCongestion Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference to this document. |
|
