Internet Documents

BCPs 200 - 299s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
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
 
Authors:B. Leiba.
Date:February 2016
Formats:txt
Updates:RFC 6241
Also:RFC 7803
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
 
Authors:Y. Sheffer, A. Farrel.
Date:July 2016
Formats:txt
Obsoletes:RFC 6982
Also:RFC 7942
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
 
Authors:W. Denniss, J. Bradley.
Date:October 2017
Formats:txt
Updates:RFC 6749
Also:RFC 8252
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
 
Authors:A. Bierman.
Date:October 2018
Formats:txt
Obsoletes:RFC 6087
Updated by:RFC 8819
Also:RFC 8407
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
 
Authors:B. Kaduk, M. Short.
Date:October 2018
Formats:txt
Updates:RFC 3961, RFC 4120
Also:RFC 8429
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
 
Authors:P. Hoffman, K. Fujiwara.
Date:March 2024
Formats:txt
Obsoletes:RFC 8499
Updates:RFC 2308
Also:RFC 9499
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
 
Authors:D.
Date:Crocker
Formats:txt
Also:RFC 8552, RFC 8553
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
 
Authors:E. Lear, Ed., S. Krishnan, M.
Date:Duke
Formats:txt
Also:RFC 8718, RFC 8719, RFC 9137
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)
 
Authors:L. Velvindron.
Date:April 2020
Formats:txt
Updates:RFC 4253
Also:RFC 8758
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
 
Authors:J. Kristoff, D. Wessels.
Date:March 2022
Formats:txt
Updates:RFC 1123, RFC 1536
Also:RFC 9210
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
 
Authors:W. Hardaker, V. Dukhovni.
Date:August 2022
Formats:txt
Updates:RFC 5155
Also:RFC 9276
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.