| |
| BCP 200 | IAB and IESG Statement on Cryptographic Technology and the Internet |
| |
| Authors: | IAB, IESG. |
| Date: | August 1996 |
| Formats: | txt |
| Also: | RFC 1984 |
|
|
|
| |
| BCP 201 | Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms |
| |
| Authors: | R. Housley. |
| Date: | November 2015 |
| Formats: | txt |
| Also: | RFC 7696 |
|
This document describes the testing result of a network utilizing aMapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.
The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines. |
|
| |
| BCP 202 | Reducing Energy Consumption of Router Advertisements |
| |
| Authors: | A. Yourtchenko, L. Colitti. |
| Date: | February 2016 |
| Formats: | txt |
| Also: | RFC 7772 |
|
Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. |
|
| |
| BCP 203 | 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. |
|
| |
| BCP 204 | Host Address Availability Recommendations |
| |
| Authors: | L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. |
| Date: | July 2016 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 205 | 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. |
|
| |
| BCP 206 | 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 |
| Also: | 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. |
|
| |
| BCP 207 | DNSSEC Roadblock Avoidance |
| |
| Authors: | W. Hardaker, O. Gudmundsson, S. Krishnaswamy. |
| Date: | November 2016 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 208 | Network Transport Circuit Breakers |
| |
| Authors: | G. Fairhurst. |
| Date: | March 2017 |
| Formats: | txt |
| Also: | RFC 8084 |
|
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. |
|
| |
| BCP 209 | Initializing a DNS Resolver with Priming Queries |
| |
| Authors: | P. Koch, M. Larson, P. Hoffman. |
| Date: | March 2017 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 210 | 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 |
| Also: | 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. |
|
| |
| BCP 211 | BGPsec Operational Considerations |
| |
| Authors: | R. Bush. |
| Date: | September 2017 |
| Formats: | txt |
| Also: | RFC 8207 |
|
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. |
|
| |
| BCP 212 | 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. |
|
| |
| BCP 213 | 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 |
| Also: | 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. |
|
| |
| BCP 214 | Mitigating the Negative Impact of Maintenance through BGP Session Culling |
| |
| Authors: | W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. |
| Date: | March 2018 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 215 | YANG Tree Diagrams |
| |
| Authors: | M. Bjorklund, L. Berger, Ed.. |
| Date: | March 2018 |
| Formats: | txt |
| Updated by: | RFC 8791 |
| Also: | RFC 8340 |
|
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. |
|
| |
| BCP 216 | 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. |
|
| |
| BCP 217 | Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) |
| |
| Authors: | P. Martinsen, T. Reddy, P. Patil. |
| Date: | July 2018 |
| Formats: | txt |
| Also: | 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). |
|
| |
| BCP 218 | 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. |
|
| |
| BCP 219 | 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. |
|
| |
| BCP 220 | IPv6 Node Requirements |
| |
| Authors: | T. Chown, J. Loughney, T. Winters. |
| Date: | January 2019 |
| Formats: | txt |
| Obsoletes: | RFC 6434 |
| Also: | RFC 8504 |
|
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. |
|
| |
| BCP 221 | Registration Data Access Protocol (RDAP) Object Tagging |
| |
| Authors: | S. Hollenbeck, A. Newton. |
| Date: | November 2018 |
| Formats: | txt |
| Updates: | RFC 7484 |
| Also: | RFC 8521 |
|
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. |
|
| |
| BCP 222 | DNS Underscored Naming |
| |
|
|
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. |
|
| |
| BCP 223 | Network Time Protocol Best Current Practices |
| |
| Authors: | D. Reilly, H. Stenn, D. Sibold. |
| Date: | July 2019 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 224 | BGPsec Router Certificate Rollover |
| |
| Authors: | B. Weis, R. Gagliano, K. Patel. |
| Date: | August 2019 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 225 | JSON Web Token Best Current Practices |
| |
| Authors: | Y. Sheffer, D. Hardt, M. Jones. |
| Date: | February 2020 |
| Formats: | txt |
| Updates: | RFC 7519 |
| Also: | RFC 8725 |
|
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. |
|
| |
| BCP 226 | Meeting Venue Selection and Policy |
| |
|
|
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. |
|
| |
| BCP 227 | Deprecating RC4 in Secure Shell (SSH) |
| |
|
|
This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status. |
|
| |
| BCP 228 | Best Practices for Securing RTP Media Signaled with SIP |
| |
| Authors: | J. Peterson, R. Barnes, R. Housley. |
| Date: | January 2021 |
| Formats: | txt |
| Also: | RFC 8862 |
|
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. |
|
| |
| BCP 229 | Deprecating Any-Source Multicast (ASM) for Interdomain Multicast |
| |
| Authors: | M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert. |
| Date: | August 2020 |
| Formats: | txt |
| Also: | 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). |
|
| |
| BCP 230 | IP Fragmentation Considered Fragile |
| |
| Authors: | R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont. |
| Date: | September 2020 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 231 | A Common Operational Problem in DNS Servers: Failure to Communicate |
| |
| Authors: | M. Andrews, R. Bellis. |
| Date: | September 2020 |
| Formats: | txt |
| Also: | RFC 8906 |
|
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. |
|
| |
| BCP 232 | Recommendations for DNS Privacy Service Operators |
| |
| Authors: | S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin. |
| Date: | October 2020 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 233 | Requirements for Time-Based Loss Detection |
| |
| Authors: | M. Allman. |
| Date: | November 2020 |
| Formats: | txt |
| Also: | RFC 8961 |
|
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. |
|
| |
| BCP 234 | Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events |
| |
| Authors: | F. Gont, J. or, R. Patterson, B. Volz. |
| Date: | August 2021 |
| Formats: | txt |
| Updates: | RFC 7084 |
| Also: | RFC 9096 |
|
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. |
|
| |
| BCP 235 | 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. |
|
| |
| BCP 236 | 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. |
|
| |
| BCP 237 | DNS Security Extensions (DNSSEC) |
| |
| Authors: | P. Hoffman. |
| Date: | February 2023 |
| Formats: | txt |
| Also: | RFC 9364 |
|
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. |
|
| |
| BCP 238 | 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 |
| Also: | 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. |
|
