| |
| BCP 100 | Early IANA Allocation of Standards Track Code Points |
| |
|
|
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. |
|
| |
| BCP 101 | Structure of the IETF Administrative Support Activity (IASA) |
| |
| Authors: | B. Haberman, J. Hall, J. Livingood, J. Arkko, T. Hardie, J. Klensin, Ed.. |
| Date: | January 2006 |
| Formats: | txt |
| Also: | RFC 8711, RFC 8714, RFC 8717 |
|
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. |
|
| |
| BCP 102 | IAB Processes for Management of IETF Liaison Relationships |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | April 2005 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 103 | Procedures for Handling Liaison Statements to and from the IETF |
| |
| Authors: | S. Trowbridge, S. Bradner, F. Baker. |
| Date: | April 2005 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 104 | Terminology for Describing Internet Connectivity |
| |
| Authors: | J. Klensin. |
| Date: | May 2005 |
| Formats: | txt |
| Also: | RFC 4084 |
|
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. |
|
| |
| BCP 105 | Embedding Globally-Routable Internet Addresses Considered Harmful |
| |
| Authors: | D. Plonka. |
| Date: | June 2005 |
| Formats: | txt |
| Also: | RFC 4085 |
|
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. |
|
| |
| BCP 106 | Randomness Requirements for Security |
| |
| Authors: | D. Eastlake 3rd, J. Schiller, S. Crocker. |
| Date: | June 2005 |
| Formats: | txt |
| Obsoletes: | RFC 1750 |
| Also: | RFC 4086 |
|
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. |
|
| |
| BCP 107 | Guidelines for Cryptographic Key Management |
| |
| Authors: | S. Bellovin, R. Housley. |
| Date: | June 2005 |
| Formats: | txt |
| Also: | RFC 4107 |
|
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. |
|
| |
| BCP 108 | 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. |
|
| |
| BCP 109 | Deprecation of "ip6.int" |
| |
| Authors: | G. Huston. |
| Date: | August 2005 |
| Formats: | txt |
| Also: | RFC 4159 |
|
This document advises of the deprecation of the use of "ip6.int" forStandards Conformant IPv6 implementations. |
|
| |
| BCP 110 | Tunneling Multiplexed Compressed RTP (TCRTP) |
| |
| Authors: | B. Thompson, T. Koren, D. Wing. |
| Date: | November 2005 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 111 | 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. |
|
| |
| BCP 112 | 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. |
|
| |
| BCP 114 | BGP Communities for Data Collection |
| |
| Authors: | D. Meyer. |
| Date: | February 2006 |
| Formats: | txt |
| Also: | RFC 4384 |
|
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. |
|
| |
| BCP 116 | IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) |
| |
| Authors: | L. Martini. |
| Date: | April 2006 |
| Formats: | txt |
| Also: | RFC 4446 |
|
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. |
|
| |
| BCP 117 | Interworking between the Session Initiation Protocol (SIP) and QSIG |
| |
| Authors: | J. Elwell, F. Derks, P. Mourot, O. Rousseau. |
| Date: | May 2006 |
| Formats: | txt |
| Updated by: | RFC 8996 |
| Also: | RFC 4497 |
|
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. |
|
| |
| BCP 118 | Considerations for Lightweight Directory Access Protocol (LDAP) Extensions |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt |
| Also: | RFC 4521 |
|
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. |
|
| |
| BCP 119 | Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents |
| |
| Authors: | A. Johnston, O. Levin. |
| Date: | August 2006 |
| Formats: | txt |
| Also: | RFC 4579 |
|
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. |
|
| |
| BCP 120 | Source-Specific Protocol Independent Multicast in 232/8 |
| |
| Authors: | D. Meyer, R. Rockell, G. Shepherd. |
| Date: | August 2006 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 121 | Multicast Source Discovery Protocol (MSDP) Deployment Scenarios |
| |
| Authors: | M. McBride, J. Meylor, D. Meyer. |
| Date: | August 2006 |
| Formats: | txt |
| Also: | 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). |
|
| |
| BCP 122 | 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. |
|
| |
| BCP 123 | 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. |
|
| |
| BCP 124 | 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. |
|
| |
| BCP 125 | Procedures for Protocol Extensions and Variations |
| |
| Authors: | S. Bradner, B. Carpenter, Ed., T. Narten. |
| Date: | December 2006 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 126 | Operation of Anycast Services |
| |
| Authors: | J. Abley, K. Lindqvist. |
| Date: | December 2006 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 127 | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP |
| |
| Authors: | F. Audet, Ed., C. Jennings, S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida, R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito. |
| Date: | April 2013 |
| Formats: | txt |
| Also: | RFC 4787, RFC 6888, RFC 7857 |
|
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. |
|
| |
| BCP 128 | Avoiding Equal Cost Multipath Treatment in MPLS Networks |
| |
| Authors: | G. Swallow, S. Bryant, L. Andersson. |
| Date: | June 2007 |
| Formats: | txt |
| Updated by: | RFC 7274 |
| Also: | RFC 4928 |
|
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. |
|
| |
| BCP 129 | 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 |
| Also: | 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. |
|
| |
| BCP 130 | IANA Considerations for OSPF |
| |
| Authors: | K. Kompella, B. Fenner. |
| Date: | July 2007 |
| Formats: | txt |
| Also: | RFC 4940 |
|
This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. |
|
| |
| BCP 131 | Symmetric RTP / RTP Control Protocol (RTCP) |
| |
| Authors: | D. Wing. |
| Date: | July 2007 |
| Formats: | txt |
| Also: | RFC 4961 |
|
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". |
|
| |
| BCP 132 | Guidance for Authentication, Authorization, and Accounting (AAA) Key Management |
| |
| Authors: | R. Housley, B. Aboba. |
| Date: | July 2007 |
| Formats: | txt |
| Also: | RFC 4962 |
|
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. |
|
| |
| BCP 133 | Specifying New Congestion Control Algorithms |
| |
| Authors: | S. Floyd, M. Allman. |
| Date: | August 2007 |
| Formats: | txt |
| Also: | RFC 5033 |
|
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. |
|
| |
| BCP 134 | Email Submission Operations: Access and Accountability Requirements |
| |
| Authors: | C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. |
| Date: | November 2007 |
| Formats: | txt |
| Updated by: | RFC 8314 |
| Also: | 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. |
|
| |
| BCP 135 | IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) |
| |
| Authors: | D. Wing, T. Eckert. |
| Date: | February 2008 |
| Formats: | txt |
| Also: | RFC 5135 |
|
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. |
|
| |
| BCP 136 | Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) |
| |
| Authors: | V. Devarapalli, P. Eronen. |
| Date: | June 2008 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 137 | ASCII Escaping of Unicode Characters |
| |
| Authors: | J. Klensin. |
| Date: | February 2008 |
| Formats: | txt |
| Also: | RFC 5137 |
|
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. |
|
| |
| BCP 138 | 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. |
|
| |
| BCP 139 | Templates for Internet-Drafts Containing MIB Modules |
| |
| Authors: | D. Harrington, Ed.. |
| Date: | July 2008 |
| Formats: | txt |
| Also: | RFC 5249 |
|
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. |
|
| |
| BCP 140 | Preventing Use of Recursive Nameservers in Reflector Attacks |
| |
| Authors: | J. Damas, F. Neves. |
| Date: | October 2008 |
| Formats: | txt |
| Also: | RFC 5358 |
|
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. |
|
| |
| BCP 141 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
| Authors: | D. Eastlake 3rd, J. Abley, Y. Li. |
| Date: | April 2024 |
| Formats: | txt |
| Obsoletes: | RFC 7042 |
| Also: | RFC 9542 |
|
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). |
|
| |
| BCP 142 | NAT Behavioral Requirements for TCP |
| |
| Authors: | S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. |
| Date: | October 2008 |
| Formats: | txt |
| Updated by: | RFC 7857 |
| Also: | 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. |
|
| |
| BCP 143 | Deployment Considerations for Lemonade-Compliant Mobile Email |
| |
| Authors: | R. Gellens. |
| Date: | October 2008 |
| Formats: | txt |
| Also: | RFC 5383 |
|
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in theIETF lemonade documents. |
|
| |
| BCP 144 | Session Initiation Protocol Service Examples |
| |
| Authors: | A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. |
| Date: | October 2008 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 145 | UDP Usage Guidelines |
| |
|
|
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. |
|
| |
| BCP 146 | Guidelines for Specifying the Use of IPsec Version 2 |
| |
| Authors: | S. Bellovin. |
| Date: | February 2009 |
| Formats: | txt |
| Also: | RFC 5406 |
|
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. |
|
| |
| BCP 147 | 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 |
| Also: | 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. |
|
| |
| BCP 148 | NAT Behavioral Requirements for ICMP |
| |
| Authors: | P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. |
| Date: | April 2009 |
| Formats: | txt |
| Updated by: | RFC 7857 |
| Also: | 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. |
|
| |
| BCP 149 | Session Initiation Protocol (SIP) Call Control - Transfer |
| |
| Authors: | R. Sparks, A. Johnston, Ed., D. Petrie. |
| Date: | June 2009 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 150 | Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol |
| |
| Authors: | R. Denis-Courmont. |
| Date: | September 2009 |
| Formats: | txt |
| Also: | RFC 5597 |
|
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. |
|
| |
| BCP 151 | H.248/MEGACO Registration Procedures |
| |
| Authors: | C. Groves, Y. Lin. |
| Date: | August 2009 |
| Formats: | txt |
| Also: | RFC 5615 |
|
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. |
|
| |
| BCP 152 | DNS Proxy Implementation Guidelines |
| |
| Authors: | R. Bellis. |
| Date: | August 2009 |
| Formats: | txt |
| Also: | RFC 5625 |
|
This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. |
|
| |
| BCP 153 | Special-Purpose IP Address Registries |
| |
| Authors: | J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger, M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman. |
| Date: | April 2012 |
| Formats: | txt txt~ |
| Also: | RFC 6598, RFC 6890, RFC 8190 |
|
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. |
|
| |
| BCP 154 | 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. |
|
| |
| BCP 155 | Nameservers for IPv4 and IPv6 Reverse Zones |
| |
| Authors: | J. Abley, T. Manderson. |
| Date: | May 2010 |
| Formats: | txt |
| Also: | RFC 5855 |
|
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). |
|
| |
| BCP 156 | Recommendations for Transport-Protocol Port Randomization |
| |
| Authors: | M. Larsen, F. Gont. |
| Date: | January 2011 |
| Formats: | txt |
| Also: | RFC 6056 |
|
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). |
|
| |
| BCP 157 | IPv6 Address Assignment to End Sites |
| |
| Authors: | T. Narten, G. Huston, L. Roberts. |
| Date: | March 2011 |
| Formats: | txt |
| Obsoletes: | RFC 3177 |
| Also: | RFC 6177 |
|
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. |
|
| |
| BCP 158 | 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). |
|
| |
| BCP 159 | Reducing the TIME-WAIT State Using TCP Timestamps |
| |
| Authors: | F. Gont. |
| Date: | April 2011 |
| Formats: | txt |
| Also: | RFC 6191 |
|
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. |
|
| |
| BCP 160 | An Architecture for Location and Location Privacy in Internet Applications |
| |
| Authors: | R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne. |
| Date: | July 2011 |
| Formats: | txt |
| Updates: | RFC 3693, RFC 3694 |
| Also: | RFC 6280 |
|
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. |
|
| |
| BCP 161 | 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 |
| Also: | 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. |
|
| |
| BCP 162 | Logging Recommendations for Internet-Facing Servers |
| |
| Authors: | A. Durand, I. Gashinsky, D. Lee, S. Sheppard. |
| Date: | June 2011 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 163 | 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. |
|
| |
| BCP 164 | IANA Considerations for Network Layer Protocol Identifiers |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | July 2011 |
| Formats: | txt |
| Also: | RFC 6328 |
|
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. |
|
| |
| BCP 165 | Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry |
| |
| Authors: | M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire. |
| Date: | August 2011 |
| Formats: | txt |
| Also: | RFC 6335, RFC 7605 |
|
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. |
|
| |
| BCP 166 | Terminology Used in Internationalization in the IETF |
| |
| Authors: | P. Hoffman, J. Klensin. |
| Date: | September 2011 |
| Formats: | txt |
| Obsoletes: | RFC 3536 |
| Also: | RFC 6365 |
|
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. |
|
| |
| BCP 167 | DomainKeys Identified Mail (DKIM) and Mailing Lists |
| |
| Authors: | M. Kucherawy. |
| Date: | September 2011 |
| Formats: | txt |
| Also: | RFC 6377 |
|
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). |
|
| |
| BCP 168 | 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. |
|
| |
| BCP 169 | Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services |
| |
| Authors: | D. McPherson, R. Donnelly, F. Scalzo. |
| Date: | October 2011 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 170 | Guidelines for Considering New Performance Metric Development |
| |
| Authors: | A. Clark, B. Claise. |
| Date: | October 2011 |
| Formats: | txt |
| Also: | RFC 6390 |
|
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. |
|
| |
| BCP 171 | Time to Remove Filters for Previously Unallocated IPv4 /8s |
| |
| Authors: | L. Vegoda. |
| Date: | November 2011 |
| Formats: | txt |
| Also: | RFC 6441 |
|
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. |
|
| |
| BCP 172 | Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP |
| |
| Authors: | W. Kumari, K. Sriram. |
| Date: | December 2011 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 173 | Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Kent, D. Kong, K. Seo, R. Watro. |
| Date: | February 2012 |
| Formats: | txt |
| Also: | RFC 6484, RFC 7382 |
|
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. |
|
| |
| BCP 174 | Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | G. Huston, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 175 | Procedures for Maintaining the Time Zone Database |
| |
| Authors: | E. Lear, P. Eggert. |
| Date: | February 2012 |
| Formats: | txt |
| Also: | RFC 6557 |
|
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. |
|
| |
| BCP 176 | IP Performance Metrics (IPPM) Standard Advancement Testing |
| |
| Authors: | R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. |
| Date: | March 2012 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 177 | IPv6 Support Required for All IP-Capable Nodes |
| |
| Authors: | W. George, C. Donley, C. Liljenstolpe, L. Howard. |
| Date: | April 2012 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 178 | Deprecating the "X-" Prefix and Similar Constructs in Application Protocols |
| |
| Authors: | P. Saint-Andre, D. Crocker, M. Nottingham. |
| Date: | June 2012 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 179 | 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. |
|
| |
| BCP 180 | DHCPv6 Redundancy Deployment Considerations |
| |
| Authors: | J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. |
| Date: | February 2013 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 181 | 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. |
|
| |
| BCP 182 | Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Gagliano, S. Kent, S. Turner. |
| Date: | April 2013 |
| Formats: | txt |
| Also: | 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). |
|
| |
| BCP 183 | A Uniform Resource Name (URN) Namespace for Examples |
| |
| Authors: | P. Saint-Andre. |
| Date: | May 2013 |
| Formats: | txt |
| Also: | RFC 6963 |
|
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. |
|
| |
| BCP 184 | Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements |
| |
| Authors: | B. Trammell, B. Claise. |
| Date: | September 2013 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 185 | Multicast in Virtual Private LAN Service (VPLS) |
| |
| Authors: | R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya, Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison. |
| Date: | February 2014 |
| Formats: | txt |
| Also: | RFC 7115, RFC 9319 |
|
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. |
|
| |
| BCP 186 | Recommendations on Filtering of IPv4 Packets Containing IPv4 Options |
| |
| Authors: | F. Gont, R. Atkinson, C. Pignataro. |
| Date: | February 2014 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 187 | Guidelines for Creating New DHCPv6 Options |
| |
| Authors: | D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. |
| Date: | May 2014 |
| Formats: | txt |
| Updates: | RFC 3315 |
| Also: | 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. |
|
| |
| BCP 188 | Pervasive Monitoring Is an Attack |
| |
| Authors: | S. Farrell, H. Tschofenig. |
| Date: | May 2014 |
| Formats: | txt |
| Also: | RFC 7258 |
|
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. |
|
| |
| BCP 189 | An Acceptable Use Policy for New ICMP Types and Codes |
| |
| Authors: | M. Shore, C. Pignataro. |
| Date: | May 2014 |
| Formats: | txt |
| Also: | RFC 7279 |
|
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. |
|
| |
| BCP 190 | 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. |
|
| |
| BCP 191 | IANA Considerations for Connectivity Fault Management (CFM) Code Points |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | July 2014 |
| Formats: | txt |
| Also: | RFC 7319 |
|
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. |
|
| |
| BCP 193 | Diameter Applications Design Guidelines |
| |
| Authors: | L. Morand, Ed., V. Fajardo, H. Tschofenig. |
| Date: | November 2014 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 194 | BGP Operations and Security |
| |
| Authors: | J. Durand, I. Pepelnjak, G. Doering. |
| Date: | February 2015 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 195 | Deprecating TLS 1.0 and TLS 1.1 |
| |
| Authors: | Y. Sheffer, R. Holz, P. Saint-Andre, K. Moriarty, S. Farrell, T. |
| Date: | Fossati |
| Formats: | txt |
| Also: | RFC 8996, RFC 9325 |
|
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. |
|
| |
| BCP 196 | Deprecating the Anycast Prefix for 6to4 Relay Routers |
| |
|
| |
| BCP 197 | IETF Recommendations Regarding Active Queue Management |
| |
| Authors: | F. Baker, Ed., G. Fairhurst, Ed.. |
| Date: | July 2015 |
| Obsoletes: | RFC 2309 |
| Also: | RFC 7567 |
|
|
|
| |
| BCP 198 | IPv6 Prefix Length Recommendation for Forwarding |
| |
| Authors: | M. Boucadair, A. Petrescu, F. Baker. |
| Date: | July 2015 |
| Formats: | txt |
| Also: | 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. |
|
| |
| BCP 199 | DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers |
| |
| Authors: | F. Gont, W. Liu, G. Van de Velde. |
| Date: | August 2015 |
| Formats: | txt |
| Also: | 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. |
|
