|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 8401 |
 Bit Index Explicit Replication (BIER) Support via IS-IS
|
|
Summary Publication date: Jun 2018 This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture. |
| RFC 8402 |
Segment Routing Architecture
|
|
Summary Publication date: Jul 2018 Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. |
| RFC 8403 |
A Scalable and Topology-Aware MPLS Data-Plane Monitoring System
|
|
Summary Publication date: Jul 2018 This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features. |
| RFC 8404 |
Effects of Pervasive Encryption on Operators
|
|
Summary Publication date: Jul 2018 Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks. |
| RFC 8405 |
Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
|
|
Summary Publication date: Jun 2018 This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations. Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events. |
| RFC 8406 |
Taxonomy of Coding Techniques for Efficient Network Communications
|
|
Summary Publication date: Jun 2018 This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups. |
| RFC 8407 |
Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
|
|
Summary Publication date: Oct 2018 This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087. |
| RFC 8408 |
Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
|
|
Summary Publication date: Jul 2018 A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session. |
| RFC 8409 |
The Entity Category Security Assertion Markup Language (SAML) Attribute Types
|
|
Summary Publication date: Aug 2018 This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories. This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group. |
| RFC 8410 |
Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
|
|
Summary Publication date: Aug 2018 This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. |
| RFC 8411 |
IANA Registration for the Cryptographic Algorithm Object Identifier Range
|
|
Summary Publication date: Aug 2018 When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. |
| RFC 8412 |
Software Inventory Message and Attributes (SWIMA) for PA-TNC
|
|
Summary Publication date: Jul 2018 This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209). |
| RFC 8413 |
Framework for Scheduled Use of Resources
|
|
Summary Publication date: Jul 2018 Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service. |
| RFC 8414 |
OAuth 2.0 Authorization Server Metadata
|
|
Summary Publication date: Jun 2018 This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. |
| RFC 8415 |
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
|
|
Summary Publication date: Nov 2018 This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. |
| RFC 8416 |
Simplified Local Internet Number Resource Management with the RPKI (SLURM)
|
|
Summary Publication date: Aug 2018 The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. |
| RFC 8417 |
Security Event Token (SET)
|
|
Summary Publication date: Jul 2018 This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. |
| RFC 8418 |
Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
|
|
Summary Publication date: Aug 2018 This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS). |
| RFC 8419 |
Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)
|
|
Summary Publication date: Aug 2018 This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. |
| RFC 8420 |
Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
|
|
Summary Publication date: Aug 2018 This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). |
| RFC 8421 |
Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
|
|
Summary Publication date: Jul 2018 This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245). |
| RFC 8422 |
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
|
|
Summary Publication date: Aug 2018 This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms. This document obsoletes RFC 4492. |
| RFC 8423 |
Reclassification of Suite B Documents to Historic Status
|
|
Summary Publication date: Jul 2018 This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430. |
| RFC 8424 |
Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
|
|
Summary Publication date: Aug 2018 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental. |
| RFC 8425 |
IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
|
|
Summary Publication date: Jul 2018 The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861. |
| RFC 8426 |
Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
|
|
Summary Publication date: Jul 2018 Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE. |
| RFC 8427 |
Representing DNS Messages in JSON
|
|
Summary Publication date: Jul 2018 Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios. |
| RFC 8428 |
Sensor Measurement Lists (SenML)
|
|
Summary Publication date: Aug 2018 This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. |
| RFC 8429 |
Deprecate Triple-DES (3DES) and RC4 in Kerberos
|
|
Summary Publication date: Oct 2018 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 to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types. |
| RFC 8430 |
RIB Information Model
|
|
Summary Publication date: Sep 2018 Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts. |
| RFC 8431 |
A YANG Data Model for the Routing Information Base (RIB)
|
|
Summary Publication date: Sep 2018 This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model. |
| RFC 8432 |
A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters
|
|
Summary Publication date: Oct 2018 The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation. This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG data model. The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology. |
| RFC 8433 |
A Simpler Method for Resolving Alert-Info URNs
|
|
Summary Publication date: Aug 2018 The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call. RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace. |
| RFC 8434 |
Requirements for Parallel NFS (pNFS) Layout Types
|
|
Summary Publication date: Aug 2018 This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661. |
| RFC 8435 |
Parallel NFS (pNFS) Flexible File Layout
|
|
Summary Publication date: Aug 2018 Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files. |
| RFC 8436 |
Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
|
|
Summary Publication date: Aug 2018 The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. |
| RFC 8437 |
IMAP UNAUTHENTICATE Extension for Connection Reuse
|
|
Summary Publication date: Aug 2018 This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. |
| RFC 8438 |
IMAP Extension for STATUS=SIZE
|
|
Summary Publication date: Aug 2018 This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. |
| RFC 8439 |
ChaCha20 and Poly1305 for IETF Protocols
|
|
Summary Publication date: Jun 2018 This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. |
| RFC 8440 |
IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
|
|
Summary Publication date: Aug 2018 This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. |
| RFC 8441 |
Bootstrapping WebSockets with HTTP/2
|
|
Summary Publication date: Sep 2018 This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. |
| RFC 8442 |
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
|
|
Summary Publication date: Sep 2018 This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection. |
| RFC 8443 |
Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
|
|
Summary Publication date: Aug 2018 This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource- Priority' header field, which is used for communications resource prioritization. |
| RFC 8444 |
OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
|
|
Summary Publication date: Nov 2018 Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header. This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document. |
| RFC 8445 |
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
|
|
Summary Publication date: Jul 2018 This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. |
| RFC 8446 |
The Transport Layer Security (TLS) Protocol Version 1.3
|
|
Summary Publication date: Aug 2018 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. |
| RFC 8447 |
IANA Registry Updates for TLS and DTLS
|
|
Summary Publication date: Aug 2018 This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. |
| RFC 8449 |
Record Size Limit Extension for TLS
|
|
Summary Publication date: Aug 2018 An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. |
| RFC 8450 |
RTP Payload Format for VC-2 High Quality (HQ) Profile
|
|
Summary Publication date: Oct 2018 This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video. The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1). |
| RFC 8451 |
Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API
|
|
Summary Publication date: Sep 2018 This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows. |
| RFC 8453 |
Framework for Abstraction and Control of TE Networks (ACTN)
|
|
Summary Publication date: Aug 2018 Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. |
| RFC 8454 |
Information Model for Abstraction and Control of TE Networks (ACTN)
|
|
Summary Publication date: Sep 2018 This document provides an information model for Abstraction and Control of TE Networks (ACTN). |
| RFC 8455 |
Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
|
|
Summary Publication date: Oct 2018 This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services. |
| RFC 8456 |
Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance
|
|
Summary Publication date: Oct 2018 This document defines methodologies for benchmarking the control- plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations. |
| RFC 8457 |
IMAP '$Important' Keyword and '\Important' Special-Use Attribute
|
|
Summary Publication date: Sep 2018 RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788. |
| RFC 8458 |
Using National Bibliography Numbers as Uniform Resource Names
|
|
Summary Publication date: Oct 2018 National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as International Standard Book Number (ISBN). A Uniform Resource Name (URN) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included. |
| RFC 8459 |
Hierarchical Service Function Chaining (hSFC)
|
|
Summary Publication date: Sep 2018 Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators. |
| RFC 8460 |
SMTP TLS Reporting
|
|
Summary Publication date: Sep 2018 A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations. |
| RFC 8461 |
SMTP MTA Strict Transport Security (MTA-STS)
|
|
Summary Publication date: Sep 2018 SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. |
| RFC 8462 |
Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
|
|
Summary Publication date: Oct 2018 The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators. The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators. A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward. |
| RFC 8463 |
A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
|
|
Summary Publication date: Sep 2018 This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. |
| RFC 8464 |
A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)
|
|
Summary Publication date: Sep 2018 This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. |
| RFC 8465 |
Using the Mobile Equipment Identity (MEID) URN as an Instance ID
|
|
Summary Publication date: Sep 2018 This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior. |
| RFC 8466 |
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
|
|
Summary Publication date: Oct 2018 This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. |
| RFC 8467 |
Padding Policies for Extension Mechanisms for DNS (EDNS(0))
|
|
Summary Publication date: Oct 2018 RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option. |
| RFC 8468 |
IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework
|
|
Summary Publication date: Nov 2018 This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation. |
| RFC 8469 |
Recommendation to Use the Ethernet Control Word
|
|
Summary Publication date: Nov 2018 The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances. This document updates RFC 4448. |
| RFC 8470 |
Using Early Data in HTTP
|
|
Summary Publication date: Sep 2018 Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. |
| RFC 8471 |
The Token Binding Protocol Version 1.0
|
|
Summary Publication date: Oct 2018 This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time. |
| RFC 8472 |
Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
|
|
Summary Publication date: Oct 2018 This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document. |
| RFC 8473 |
Token Binding over HTTP
|
|
Summary Publication date: Oct 2018 This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471). |
| RFC 8474 |
IMAP Extension for Object Identifiers
|
|
Summary Publication date: Sep 2018 This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. |
| RFC 8475 |
Using Conditional Router Advertisements for Enterprise Multihoming
|
|
Summary Publication date: Oct 2018 This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028. |
| RFC 8477 |
Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
|
|
Summary Publication date: Oct 2018 This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
| RFC 8478 |
Zstandard Compression and the application/zstd Media Type
|
|
Summary Publication date: Oct 2018 Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME). Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. |
| RFC 8479 |
Storing Validation Parameters in PKCS#8
|
|
Summary Publication date: Sep 2018 This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958. The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard. |
| RFC 8480 |
6TiSCH Operation Sublayer (6top) Protocol (6P)
|
|
Summary Publication date: Nov 2018 This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF. |
| RFC 8481 |
Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)
|
|
Summary Publication date: Sep 2018 Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration. |
| RFC 8483 |
Yeti DNS Testbed
|
|
Summary Publication date: Oct 2018 Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built). |
| RFC 8484 |
DNS Queries over HTTPS (DoH)
|
|
Summary Publication date: Oct 2018 This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. |
| RFC 8485 |
Vectors of Trust
|
|
Summary Publication date: Oct 2018 This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction. |
| RFC 8486 |
Ambisonics in an Ogg Opus Container
|
|
Summary Publication date: Oct 2018 This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. |
| RFC 8487 |
Mtrace Version 2: Traceroute Facility for IP Multicast
|
|
Summary Publication date: Oct 2018 This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply. |
| RFC 8491 |
Signaling Maximum SID Depth (MSD) Using IS-IS
|
|
Summary Publication date: Nov 2018 This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. |
| RFC 8493 |
The BagIt File Packaging Format (V1.0)
|
|
Summary Publication date: Oct 2018 This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer. |
| RFC 8494 |
Multicast Email (MULE) over Allied Communications Publication (ACP) 142
|
|
Summary Publication date: Nov 2018 Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409). This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism. This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics. |
| RFC 8495 |
Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
|
|
Summary Publication date: Nov 2018 This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer". |
| RFC 8496 |
P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)
|
|
Summary Publication date: Oct 2018 This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA. |
| RFC 8497 |
Marking SIP Messages to Be Logged
|
|
Summary Publication date: Nov 2018 SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end. This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks. |
