| |
| RFC 8700 | Fifty Years of RFCs |
| |
|
|
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540. |
|
| |
| RFC 8701 | Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility |
| |
|
|
This document describes GREASE (Generate Random Extensions AndSustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. |
|
| |
| RFC 8702 | Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document updates the "Cryptographic Message Syntax (CMS)Algorithms" (RFC 3370) and describes the conventions for using theSHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme(RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA).The conventions for the associated signer public keys in CMS are also described. |
|
| |
| RFC 8703 | Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension |
| |
| Authors: | R. Taylor, S. Ratliff. |
| Date: | February 2020 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8703 |
|
The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC8175) assumes that every modem in the radio network has an attachedDLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.
This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. |
|
| |
| RFC 8704 | Enhanced Feasible-Path Unicast Reverse Path Forwarding |
| |
|
|
This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38).Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704).However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. |
|
| |
| RFC 8705 | OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens |
| |
| Authors: | B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt. |
| Date: | February 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8705 |
|
This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security(TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. |
|
| |
| RFC 8706 | Restart Signaling for IS-IS |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.
This document obsoletes RFC 5306. |
|
| |
| RFC 8707 | Resource Indicators for OAuth 2.0 |
| |
| Authors: | B. Campbell, J. Bradley, H. Tschofenig. |
| Date: | February 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8707 |
|
This document specifies an extension to the OAuth 2.0 AuthorizationFramework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. |
|
| |
| RFC 8708 | Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. |
|
| |
| RFC 8709 | Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol |
| |
|
|
This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol.Accordingly, this RFC updates RFC 4253. |
|
| |
| RFC 8710 | Multipart Content-Format for the Constrained Application Protocol (CoAP) |
| |
| Authors: | T. Fossati, K. Hartke, C. Bormann. |
| Date: | February 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8710 |
|
This memo defines application/multipart-core, an application- independent media type that can be used to combine representations of zero or more different media types (each with a ConstrainedApplication Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead. |
|
| |
| RFC 8711 | Structure of the IETF Administrative Support Activity, Version 2.0 |
| |
|
|
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe theIETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLCBoard (IETF LLC Board), the IETF Executive Director, and the InternetSociety in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.
This document obsoletes RFC 4071, RFC 4333, and RFC 7691. |
|
| |
| RFC 8712 | The IETF-ISOC Relationship |
| |
|
|
This document summarizes the Internet Engineering Task Force (IETF) -Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in2018. The IASA was revised under a new "IASA 2.0" structure by theIASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031. |
|
| |
| RFC 8713 | IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC(IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF AdministrativeSupport Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.
This document obsoletes RFC 7437 and RFC 8318. |
|
| |
| RFC 8714 | Update to the Process for Selection of Trustees for the IETF Trust |
| |
|
|
This memo updates the process for selection of Trustees for the IETFTrust. Previously, the IETF Administrative Oversight Committee(IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETFAdministrative Support Activity (IASA). This memo specifies that theTrustees shall be selected separately.
This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today. |
|
| |
| RFC 8715 | IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust |
| |
|
|
This document captures the rationale for the changes introduced inRFC 8714, "Update to the Process for Selection of Trustees for theIETF Trust".
At the time RFC 8714 was published, the changes to the IETFAdministrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF AdministrativeOversight Committee (IAOC), which was being phased out, had served asTrustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. |
|
| |
| RFC 8716 | Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC |
| |
|
|
The IETF Anti-Harassment Procedures are described in RFC 7776.
The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.
RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates. |
|
| |
| RFC 8717 | IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology |
| |
|
|
In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes. |
|
| |
| RFC 8718 | IETF Plenary Meeting Venue Selection Process |
| |
|
|
The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process. |
|
| |
| RFC 8719 | High-Level Guidance for the Meeting Policy of the IETF |
| |
|
|
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy. |
|
| |
| RFC 8720 | Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries |
| |
|
|
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries. |
|
| |
| RFC 8721 | Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents |
| |
|
|
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative OversightCommittee (IAOC), which was part of the IETF Administrative SupportActivity (IASA). |
|
| |
| RFC 8722 | Defining the Role and Function of IETF Protocol Parameter Registry Operators |
| |
| Authors: | D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed.. |
| Date: | February 2020 |
| Formats: | txt html json xml pdf |
| Obsoletes: | RFC 6220 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8722 |
|
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model. |
|
| |
| RFC 8723 | Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | C. Jennings, P. Jones, R. Barnes, A.B. Roach. |
| Date: | April 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8723 |
|
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time TransportProtocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by- hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of futureSRTP transforms with different properties. |
|
| |
| RFC 8724 | SCHC: Generic Framework for Static Context Header Compression and Fragmentation |
| |
| Authors: | A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga. |
| Date: | April 2020 |
| Formats: | txt json xml html pdf |
| Updated by: | RFC 9441 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8724 |
|
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.
This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.
The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.This document standardizes the exchange over the LPWAN between twoSCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. |
|
| |
| RFC 8725 | JSON Web Token Best Current Practices |
| |
|
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. ThisBest Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. |
|
| |
| RFC 8726 | How Requests for IANA Action Will Be Handled on the Independent Stream |
| |
|
|
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by theIETF and documented in RFCs developed on the IETF Stream.
The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of theIndependent Submissions Editor (ISE).
This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent SubmissionStream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. |
|
| |
| RFC 8727 | JSON Binding of the Incident Object Description Exchange Format |
| |
| Authors: | T. Takahashi, R. Danyliw, M. Suzuki. |
| Date: | August 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8727 |
|
The Incident Object Description Exchange Format (IODEF) defined inRFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary ObjectRepresentation (CBOR). |
|
| |
| RFC 8728 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity(IASA) and related structures with those defined by the IASA 2.0Model. |
|
| |
| RFC 8729 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. This document obsoletesRFC 4844. |
|
| |
| RFC 8730 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrationLimited Liability Company (LLC).
This version obsoletes RFC 6548 to replace all references to theInternet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure. |
|
| |
| RFC 8731 | Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 |
| |
| Authors: | A. Adamantiadis, S. Josefsson, M. Baushke. |
| Date: | February 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8731 |
|
This document describes the specification for using Curve25519 andCurve448 key exchange methods in the Secure Shell (SSH) protocol. |
|
| |
| RFC 8732 | Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 |
| |
|
|
This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used byGeneric Security Service (GSS) key exchanges. |
|
| |
| RFC 8733 | Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE |
| |
| Authors: | D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang. |
| Date: | February 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8733 |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Stateful PCE extensions allow stateful control of MPLS-TE LabelSwitched Paths (LSPs) using PCEP.
The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs. |
|
| |
| RFC 8734 | Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3 |
| |
| Authors: | L. Bruckert, J. Merkle, M. Lochter. |
| Date: | February 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8734 |
|
Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS1.3.
This document provides the necessary protocol mechanisms for usingECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF. |
|
| |
| RFC 8735 | Scenarios and Simulation Results of PCE in a Native IP Network |
| |
| Authors: | A. Wang, X. Huang, C. Kou, Z. Li, P. Mi. |
| Date: | February 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8735 |
|
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying thePath Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios. |
|
| |
| RFC 8736 | PIM Message Type Space Extension and Reserved Bits |
| |
|
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.
This document obsoletes RFC 6166. |
|
| |
| RFC 8737 | Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension |
| |
|
|
This document specifies a new challenge for the Automated CertificateManagement Environment (ACME) protocol that allows for domain control validation using TLS. |
|
| |
| RFC 8738 | Automated Certificate Management Environment (ACME) IP Identifier Validation Extension |
| |
|
|
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. |
|
| |
| RFC 8739 | Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) |
| |
| Authors: | Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati. |
| Date: | March 2020 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8739 |
|
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an AutomatedCertificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. |
|
| |
| RFC 8740 | Using TLS 1.3 with HTTP/2 |
| |
|
|
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction. |
|
| |
| RFC 8741 | Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) |
| |
| Authors: | A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi. |
| Date: | March 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8741 |
|
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) TrafficEngineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A PathComputation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.
This document describes an extension to the Path Computation ElementCommunication Protocol (PCEP) to enable a PCE to make requests for such control. |
|
| |
| RFC 8742 | Concise Binary Object Representation (CBOR) Sequences |
| |
|
|
This document describes the Concise Binary Object Representation(CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.
Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBORSequences. |
|
| |
| RFC 8743 | Multiple Access Management Services Multi-Access Management Services (MAMS) |
| |
| Authors: | S. Kanugovi, F. Baboescu, J. Zhu, S. Seo. |
| Date: | March 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8743 |
|
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.
This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance. |
|
| |
| RFC 8744 | Issues and Requirements for Server Name Identification (SNI) Encryption in TLS |
| |
|
|
This document describes the general problem of encrypting the ServerName Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co- tenancy" solution, and presents requirements for future TLS-layer solutions.
In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises. |
|
| |
| RFC 8745 | Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE |
| |
| Authors: | H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi. |
| Date: | March 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8745 |
|
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation ElementCommunication Protocol (PCEP) Multiprotocol Label Switching TrafficEngineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection. |
|
| |
| RFC 8746 | Concise Binary Object Representation (CBOR) Tags for Typed Arrays |
| |
|
|
The Concise Binary Object Representation (CBOR), as defined in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document makes use of this extensibility to define a number ofCBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. |
|
| |
| RFC 8747 | Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) |
| |
| Authors: | M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. |
| Date: | March 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8747 |
|
This specification describes how to declare in a CBOR Web Token (CWT)(which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens(JWTs). |
|
| |
| RFC 8748 | Registry Fee Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | R. Carney, G. Brown, J. Frakes. |
| Date: | March 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8748 |
|
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method forExtensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees. |
|
| |
| RFC 8749 | Moving DNSSEC Lookaside Validation (DLV) to Historic Status |
| |
|
|
This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection. |
|
| |
| RFC 8750 | Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) |
| |
| Authors: | D. Migault, T. Guggemos, Y. Nir. |
| Date: | March 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8750 |
|
Encapsulating Security Payload (ESP) sends an initialization vector(IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take theIV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP SequenceNumber (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case ofAES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. |
|
| |
| RFC 8751 | Hierarchical Stateful Path Computation Element (PCE) |
| |
| Authors: | D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King. |
| Date: | March 2020 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8751 |
|
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients(PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests.This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.
Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture. |
|
| |
| RFC 8752 | Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) |
| |
|
|
The Exploring Synergy between Content Aggregation and the PublisherEcosystem (ESCAPE) Workshop was convened by the Internet ArchitectureBoard (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
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 8753 | Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions |
| |
|
|
The standards for Internationalized Domain Names in Applications(IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility withUnicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience. |
|
| |
| RFC 8754 | IPv6 Segment Routing Header (SRH) |
| |
| Authors: | C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer. |
| Date: | March 2020 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8754 |
|
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header(SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. |
|
| |
| RFC 8755 | Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions |
| |
|
|
The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inSecure/Multipurpose Internet Mail Extensions (S/MIME) as specified inRFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8756 | Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS |
| |
|
|
This document specifies a profile of the Certificate Management overCMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm(CNSA) Suite published by the United States Government.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8757 | Dynamic Link Exchange Protocol (DLEP) Latency Range Extension |
| |
| Authors: | B. Cheng, L. Berger, Ed.. |
| Date: | March 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8757 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) to provide the range of latency that can be experienced on a link. |
|
| |
| RFC 8758 | Deprecating RC4 in Secure Shell (SSH) |
| |
|
|
This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status. |
|
| |
| RFC 8759 | RTP Payload for Timed Text Markup Language (TTML) |
| |
|
|
This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML. |
|
| |
| RFC 8760 | The Session Initiation Protocol (SIP) Digest Access Authentication Scheme |
| |
|
|
This document updates RFC 3261 by modifying the Digest AccessAuthentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 andSHA-512/256, to replace the obsolete MD5 algorithm. |
|
| |
| RFC 8761 | Video Codec Requirements and Evaluation Methodology |
| |
| Authors: | A. Filippov, A. Norkin, J.R. Alvarez. |
| Date: | April 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8761 |
|
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled. |
|
| |
| RFC 8762 | Simple Two-Way Active Measurement Protocol |
| |
|
|
This document describes the Simple Two-way Active MeasurementProtocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. |
|
| |
| RFC 8763 | Deployment Considerations for Information-Centric Networking (ICN) |
| |
| Authors: | A. Rahman, D. Trossen, D. Kutscher, R. Ravindran. |
| Date: | April 2020 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8763 |
|
Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-CentricNetworking Research Group (ICNRG). |
|
| |
| RFC 8764 | Apple's DNS Long-Lived Queries Protocol |
| |
|
|
Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending theDNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From2005 onwards, LLQ was implemented in Apple products including Mac OSX, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765,"DNS Push Notifications", which builds on experience gained with theLLQ protocol to create a superior replacement.
The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS PushNotifications. |
|
| |
| RFC 8765 | DNS Push Notifications |
| |
| Authors: | T. Pusateri, S. Cheshire. |
| Date: | June 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8765 |
|
The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes toDNS records, called DNS Push Notifications. |
|
| |
| RFC 8766 | Discovery Proxy for Multicast DNS-Based Service Discovery |
| |
|
|
This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. |
|
| |
| RFC 8767 | Serving Stale Data to Improve DNS Resiliency |
| |
|
|
This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. |
|
| |
| RFC 8768 | Constrained Application Protocol (CoAP) Hop-Limit Option |
| |
| Authors: | M. Boucadair, T. Reddy.K, J. Shallow. |
| Date: | March 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8768 |
|
The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. |
|
| |
| RFC 8769 | Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) |
| |
|
|
Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax(CMS) is still a widely used method of doing message-based security.This document defines a set of content types for CMS that hold CBOR content. |
|
| |
| RFC 8770 | Host Router Support for OSPFv2 |
| |
| Authors: | K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar. |
| Date: | April 2020 |
| Formats: | txt xml pdf html json |
| Updates: | RFC 6987 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8770 |
|
The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit(H-bit). This bit enables a router to advertise that it is a non- transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updatesRFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA)Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively. |
|
| |
| RFC 8771 | The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) |
| |
|
|
Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes theInternationalized Deliberately Unreadable Network NOtation("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity. |
|
| |
| RFC 8772 | The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP) |
| |
| Authors: | S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang. |
| Date: | May 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8772 |
|
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP).China Mobile, Huawei Technologies, and ZTE have developed a simpleCUPS control channel protocol to support such communication: theSimple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.
This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability. |
|
| |
| RFC 8773 | TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key |
| |
|
|
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). |
|
| |
| RFC 8774 | The Quantum Bug |
| |
|
|
The age of quantum networking is upon us, and with it comes"entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on someInternet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time. |
|
| |
| RFC 8775 | PIM Designated Router Load Balancing |
| |
| Authors: | Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green. |
| Date: | April 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8775 |
|
On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to thePIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers. |
|
| |
| RFC 8776 | Common YANG Data Types for Traffic Engineering |
| |
| Authors: | T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin. |
| Date: | June 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8776 |
|
This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model TrafficEngineering (TE) configuration and state capabilities. |
|
| |
| RFC 8777 | DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery |
| |
|
|
This document updates RFC 7450, "Automatic Multicast Tunneling" (orAMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined. |
|
| |
| RFC 8778 | Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption(COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. |
|
| |
| RFC 8779 | Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS |
| |
| Authors: | C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed.. |
| Date: | July 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8779 |
|
A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC7025.
This memo provides extensions to the Path Computation ElementCommunication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. |
|
| |
| RFC 8780 | The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) |
| |
| Authors: | Y. Lee, Ed., R. Casellas, Ed.. |
| Date: | July 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8780 |
|
This document provides Path Computation Element CommunicationProtocol (PCEP) extensions for the support of Routing and WavelengthAssignment (RWA) in Wavelength Switched Optical Networks (WSONs).Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation. |
|
| |
| RFC 8781 | Discovering PREF64 in Router Advertisements |
| |
|
|
This document specifies a Neighbor Discovery option to be used inRouter Advertisements (RAs) to communicate prefixes of NetworkAddress and Protocol Translation from IPv6 clients to IPv4 servers(NAT64) to hosts. |
|
| |
| RFC 8782 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification |
| |
| Authors: | T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague. |
| Date: | May 2020 |
| Formats: | txt pdf xml json html |
| Obsoleted by: | RFC 9132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8782 |
|
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. |
|
| |
| RFC 8783 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed.. |
| Date: | May 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8783 |
|
The document specifies a Distributed Denial-of-Service Open ThreatSignaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
This is a companion document to "Distributed Denial-of-Service OpenThreat Signaling (DOTS) Signal Channel Specification" (RFC 8782). |
|
| |
| RFC 8784 | Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security |
| |
| Authors: | S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov. |
| Date: | June 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8784 |
|
The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet KeyExchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.It is anticipated that IKEv2 will be extended to support quantum- secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. |
|
| |
| RFC 8785 | JSON Canonicalization Scheme (JCS) |
| |
| Authors: | A. Rundgren, B. Jordan, S. Erdtman. |
| Date: | June 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8785 |
|
Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.
This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation ofJSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to theInternet JSON (I-JSON) subset, and by using deterministic property sorting. |
|
| |
| RFC 8786 | Updated Rules for Processing Stateful PCE Request Parameters Flags |
| |
|
|
Extensions to the Path Computation Element Communication Protocol(PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCERequest Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.
This document updates RFC 8231 by defining the correct behaviors. |
|
| |
| RFC 8787 | Location Source Parameter for the SIP Geolocation Header Field |
| |
| Authors: | J. Winterbottom, R. Jesske, B. Chatras, A. Hutton. |
| Date: | May 2020 |
| Formats: | txt json xml pdf html |
| Updates: | RFC 6442 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8787 |
|
There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to theGeolocation header field can identify itself using its hostname.This document updates RFC 6442. |
|
| |
| RFC 8788 | Eligibility for the 2020-2021 Nominating Committee |
| |
|
|
The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in- person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future. |
|
| |
| RFC 8789 | IETF Stream Documents Require IETF Rough Consensus |
| |
|
|
This document requires that the IETF never publish any IETF StreamRFCs without IETF rough consensus. This updates RFC 2026. |
|
| |
| RFC 8790 | FETCH and PATCH with Sensor Measurement Lists (SenML) |
| |
|
|
The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol(CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model. |
|
| |
| RFC 8791 | YANG Data Structure Extensions |
| |
|
|
This document describes YANG mechanisms for defining abstract data structures with YANG. |
|
| |
| RFC 8792 | Handling Long Lines in Content of Internet-Drafts and RFCs |
| |
| Authors: | K. Watsen, E. Auerswald, A. Farrel, Q. Wu. |
| Date: | June 2020 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8792 |
|
This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. |
|
| |
| RFC 8793 | Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology |
| |
| Authors: | B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin. |
| Date: | June 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8793 |
|
Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named DataNetworking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are otherICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 8794 | Extensible Binary Meta Language |
| |
|
|
This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage.EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines howEBML Schemas are created to convey the semantics of an EBML Document. |
|
| |
| RFC 8795 | YANG Data Model for Traffic Engineering (TE) Topologies |
| |
| Authors: | X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Gonzalez de Dios. |
| Date: | August 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8795 |
|
This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. |
|
| |
| RFC 8796 | RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels |
| |
| Authors: | M. Taillon, T. Saad, Ed., R. Gandhi, A. Deshmukh, M. Jork, V. Beeram. |
| Date: | July 2020 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 4090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8796 |
|
This document updates RFC 4090 for the Resource Reservation Protocol(RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute(FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and theMerge Point (MP) nodes to be independent of the number of protectedLabel Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them. |
|
| |
| RFC 8797 | Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 |
| |
|
|
This document specifies the format of Remote Direct Memory Access -Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166. |
|
| |
| RFC 8798 | Additional Units for Sensor Measurement Lists (SenML) |
| |
|
|
The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry. |
|
| |
| RFC 8799 | Limited Domains and Internet Protocols |
| |
|
|
There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.
This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. |
|
