| |
| RFC 8900 | IP Fragmentation Considered Fragile |
| |
| Authors: | R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont. |
| Date: | September 2020 |
| Formats: | txt html pdf json xml |
| Also: | BCP 0230 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8900 |
|
This document describes IP fragmentation and explains how it introduces fragility to Internet communication.
This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. |
|
| |
| RFC 8901 | Multi-Signer DNSSEC Models |
| |
| Authors: | S. Huque, P. Aras, J. Dickinson, J. Vcelak, D. Blacka. |
| Date: | September 2020 |
| Formats: | txt html pdf json xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8901 |
|
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations. |
|
| |
| RFC 8902 | TLS Authentication Using Intelligent Transport System (ITS) Certificates |
| |
| Authors: | M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A. Serhrouchni, H. Labiod. |
| Date: | September 2020 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8902 |
|
The IEEE and ETSI have specified a type of end-entity certificate.This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities. |
|
| |
| RFC 8903 | Use Cases for DDoS Open Threat Signaling |
| |
| Authors: | R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka. |
| Date: | May 2021 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8903 |
|
The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoSMitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is. |
|
| |
| RFC 8904 | DNS Whitelist (DNSWL) Email Authentication Method Extension |
| |
|
|
This document describes an email authentication method compliant withRFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.
This document does not consider blacklists. |
|
| |
| RFC 8905 | The 'payto' URI Scheme for Payments |
| |
|
|
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. |
|
| |
| RFC 8906 | A Common Operational Problem in DNS Servers: Failure to Communicate |
| |
|
|
The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.
This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.
The document does not look at the DNS data itself, just the structure of the responses. |
|
| |
| RFC 8907 | The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol |
| |
| Authors: | T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant. |
| Date: | September 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8907 |
|
This document describes the Terminal Access Controller Access-ControlSystem Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers. |
|
| |
| RFC 8908 | Captive Portal API |
| |
| Authors: | T. Pauly, Ed., D. Thakore, Ed.. |
| Date: | September 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8908 |
|
This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their CaptivePortal sessions. |
|
| |
| RFC 8909 | Registry Data Escrow Specification |
| |
|
|
This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries. |
|
| |
| RFC 8910 | Captive-Portal Identification in DHCP and Router Advertisements (RAs) |
| |
|
|
In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a RouterAdvertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679. |
|
| |
| RFC 8911 | Registry for Performance Metrics |
| |
| Authors: | M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter. |
| Date: | November 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8911 |
|
This document defines the format for the IANA Registry of PerformanceMetrics. This document also gives a set of guidelines for RegisteredPerformance Metric requesters and reviewers. |
|
| |
| RFC 8912 | Initial Performance Metrics Registry Entries |
| |
| Authors: | A. Morton, M. Bagnulo, P. Eardley, K. D'Souza. |
| Date: | November 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8912 |
|
This memo defines the set of initial entries for the IANA Registry ofPerformance Metrics. The set includes UDP Round-Trip Latency andLoss, Packet Delay Variation, DNS Response Latency and Loss, UDPPoisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss. |
|
| |
| RFC 8913 | Two-Way Active Measurement Protocol (TWAMP) YANG Data Model |
| |
| Authors: | R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed.. |
| Date: | November 2021 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8913 |
|
This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).This document defines the TWAMP data model through Unified ModelingLanguage (UML) class diagrams and formally specifies it using theYANG data modeling language (RFC 7950). The data model is compliant with the Network Management Datastore Architecture (NMDA). |
|
| |
| RFC 8914 | Extended DNS Errors |
| |
| Authors: | W. Kumari, E. Hunt, R. Arends, W. Hardaker, D. Lawrence. |
| Date: | October 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8914 |
|
This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. |
|
| |
| RFC 8915 | Network Time Security for the Network Time Protocol |
| |
| Authors: | D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad. |
| Date: | September 2020 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8915 |
|
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols.The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTSExtension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies. |
|
| |
| RFC 8916 | A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | X. Liu, Z. Zhang, Ed., A. Peter, M. Sivakumar, F. Guo, P. McAllister. |
| Date: | October 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8916 |
|
This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations. |
|
| |
| RFC 8917 | The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag |
| |
|
|
This document adds the 'LoST-Validation' service tag to theStraightforward-Naming Authority PoinTeR (S-NAPTR) ApplicationService Tag IANA registry. This tag can appear in a Naming AuthorityPointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifyingLoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation. |
|
| |
| RFC 8918 | Invalid TLV Handling in IS-IS |
| |
|
|
The key to the extensibility of the Intermediate System toIntermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit(PDU) is received.
This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.
This document updates RFCs 5305 and 6232. |
|
| |
| RFC 8919 | IS-IS Application-Specific Link Attributes |
| |
| Authors: | L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. |
| Date: | October 2020 |
| Formats: | txt html json xml pdf |
| Obsoleted by: | RFC 9479 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8919 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. |
|
| |
| RFC 8920 | OSPF Application-Specific Link Attributes |
| |
| Authors: | P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. |
| Date: | October 2020 |
| Formats: | txt pdf xml html json |
| Obsoleted by: | RFC 9492 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8920 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings. |
|
| |
| RFC 8921 | Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) |
| |
| Authors: | M. Boucadair, Ed., C. Jacquenet, D. Zhang, P. Georgatsos. |
| Date: | October 2020 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8921 |
|
This document defines the Connectivity Provisioning NegotiationProtocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.
CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, ContentDelivery Networks, etc. |
|
| |
| RFC 8922 | A Survey of the Interaction between Security Protocols and Transport Services |
| |
| Authors: | T. Enghardt, T. Pauly, C. Perkins, K. Rose, C. Wood. |
| Date: | October 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8922 |
|
This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of theIETF, and those included represent a superset of features a TransportServices system may need to support. |
|
| |
| RFC 8923 | A Minimal Set of Transport Services for End Systems |
| |
|
|
This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. |
|
| |
| RFC 8924 | Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework |
| |
| Authors: | S. Aldrin, C. Pignataro, Ed., N. Kumar, Ed., R. Krishnan, A. Ghanwani. |
| Date: | October 2020 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8924 |
|
This document provides a reference framework for Operations,Administration, and Maintenance (OAM) for Service Function Chaining(SFC). |
|
| |
| RFC 8925 | IPv6-Only Preferred Option for DHCPv4 |
| |
| Authors: | L. Colitti, J. Linkova, M. Richardson, T. Mrugalski. |
| Date: | October 2020 |
| Formats: | txt html xml pdf json |
| Updates: | RFC 2563 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8925 |
|
This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updatesRFC 2563 to specify DHCPv4 server behavior when the server receives aDHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document. |
|
| |
| RFC 8926 | Geneve: Generic Network Virtualization Encapsulation |
| |
| Authors: | J. Gross, Ed., I. Ganga, Ed., T. Sridhar, Ed.. |
| Date: | November 2020 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8926 |
|
Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. |
|
| |
| RFC 8927 | JSON Type Definition |
| |
|
|
This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators.To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.
This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD. |
|
| |
| RFC 8928 | Address-Protected Neighbor Discovery for Low-Power and Lossy Networks |
| |
| Authors: | P. Thubert, Ed., B. Sarikaya, M. Sethi, R. Struik. |
| Date: | November 2020 |
| Formats: | txt pdf html xml json |
| Updates: | RFC 8505 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8928 |
|
This document updates the IPv6 over Low-Power Wireless Personal AreaNetwork (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs6775 and 8505. The new extension is called Address-ProtectedNeighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power andLossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with theCrypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation. |
|
| |
| RFC 8929 | IPv6 Backbone Router |
| |
|
|
This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called"Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN). |
|
| |
| RFC 8930 | On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network |
| |
| Authors: | T. Watteyne, Ed., P. Thubert, Ed., C. Bormann. |
| Date: | November 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8930 |
|
This document provides generic rules to enable the forwarding of anIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC4944 and Virtual Reassembly Buffers (VRBs). |
|
| |
| RFC 8931 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery |
| |
|
|
This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network. |
|
| |
| RFC 8932 | Recommendations for DNS Privacy Service Operators |
| |
| Authors: | S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin. |
| Date: | October 2020 |
| Formats: | txt json html pdf xml |
| Also: | BCP 0232 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8932 |
|
This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.
This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNSSecurity Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841. |
|
| |
| RFC 8933 | Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection |
| |
|
|
This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. |
|
| |
| RFC 8934 | PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE |
| |
| Authors: | H. Chen, Ed., Y. Zhuang, Ed., Q. Wu, D. Ceccarelli. |
| Date: | October 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8934 |
|
This document defines a set of extensions to the stateful PCECommunication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413. |
|
| |
| RFC 8935 | Push-Based Security Event Token (SET) Delivery Using HTTP |
| |
| Authors: | A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. |
| Date: | November 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8935 |
|
This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. |
|
| |
| RFC 8936 | Poll-Based Security Event Token (SET) Delivery Using HTTP |
| |
| Authors: | A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. |
| Date: | November 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8936 |
|
This specification defines how a series of Security Event Tokens(SETs) can be delivered to an intended recipient using HTTP POST overTLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance. |
|
| |
| RFC 8937 | Randomness Improvements for Security Protocols |
| |
| Authors: | C. Cremers, L. Garratt, S. Smyshlyaev, N. Sullivan, C. Wood. |
| Date: | October 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8937 |
|
Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable"cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 8938 | Deterministic Networking (DetNet) Data Plane Framework |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. |
| Date: | November 2020 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8938 |
|
This document provides an overall framework for the DeterministicNetworking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well. |
|
| |
| RFC 8939 | Deterministic Networking (DetNet) Data Plane: IP |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant. |
| Date: | November 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8939 |
|
This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). |
|
| |
| RFC 8940 | Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) |
| |
|
|
RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber IdentityModule (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation ofSession-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods. |
|
| |
| RFC 8941 | Structured Field Values for HTTP |
| |
| Authors: | M. Nottingham, P-H. Kamp. |
| Date: | February 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8941 |
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handleHTTP header and trailer fields, known as "Structured Fields","Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. |
|
| |
| RFC 8942 | HTTP Client Hints |
| |
|
|
HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.
This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." |
|
| |
| RFC 8943 | Concise Binary Object Representation (CBOR) Tags for Date |
| |
| Authors: | M. Jones, A. Nadalin, J. Richter. |
| Date: | November 2020 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8943 |
|
The Concise Binary Object Representation (CBOR), as specified 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.
In CBOR, one point of extensibility is the definition of CBOR tags.RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within theGregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time.This specification is the reference document for IANA registration of the CBOR tags defined. |
|
| |
| RFC 8944 | A YANG Data Model for Layer 2 Network Topologies |
| |
| Authors: | J. Dong, X. Wei, Q. Wu, M. Boucadair, A. Liu. |
| Date: | November 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8944 |
|
This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2. |
|
| |
| RFC 8945 | Secret Key Transaction Authentication for DNS (TSIG) |
| |
|
|
This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.
No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.
This document obsoletes RFCs 2845 and 4635. |
|
| |
| RFC 8946 | Personal Assertion Token (PASSporT) Extension for Diverted Calls |
| |
|
|
The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios.Also specified here is an encapsulation mechanism for nesting aPASSporT within another PASSporT that assists relying parties in some diversion scenarios.
This document updates RFC 8224. |
|
| |
| RFC 8947 | Link-Layer Address Assignment Mechanism for DHCPv6 |
| |
| Authors: | B. Volz, T. Mrugalski, C. Bernardos. |
| Date: | December 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8947 |
|
In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable.Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary. |
|
| |
| RFC 8948 | Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 |
| |
| Authors: | CJ. Bernardos, A. Mourad. |
| Date: | December 2020 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8948 |
|
The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.
The IEEE is developing protocols to assign addresses (IEEE P802.1CQ).There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.
This document proposes extensions to DHCPv6 protocols to enable aDHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option(QUAD) is defined for this purpose. |
|
| |
| RFC 8949 | Concise Binary Object Representation (CBOR) |
| |
|
|
The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. |
|
| |
| RFC 8950 | Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop |
| |
| Authors: | S. Litkowski, S. Agrawal, K. Ananthamurthy, K. Patel. |
| Date: | November 2020 |
| Formats: | txt json xml html pdf |
| Obsoletes: | RFC 5549 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8950 |
|
Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI.
This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI andVPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC5549. |
|
| |
| RFC 8951 | Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 |
| |
|
|
This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.
This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present. |
|
| |
| RFC 8952 | Captive Portal Architecture |
| |
| Authors: | K. Larose, D. Dolson, H. Liu. |
| Date: | November 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8952 |
|
This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. |
|
| |
| RFC 8953 | Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report |
| |
|
|
The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28February and 1 March 2019 in Cambridge, Massachusetts, USA.Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption. |
|
| |
| RFC 8954 | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
|
This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and theNonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updatesRFC 6960. |
|
| |
| RFC 8955 | Dissemination of Flow Specification Rules |
| |
|
|
This document defines a Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic FlowSpecifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the FlowSpecification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.
This document obsoletes both RFC 5575 and RFC 7674. |
|
| |
| RFC 8956 | Dissemination of Flow Specification Rules for IPv6 |
| |
| Authors: | C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed.. |
| Date: | December 2020 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8956 |
|
"Dissemination of Flow Specification Rules" (RFC 8955) provides aBorder Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.
This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. |
|
| |
| RFC 8957 | Synonymous Flow Label Framework |
| |
| Authors: | S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8957 |
|
RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router. |
|
| |
| RFC 8958 | Updated Registration Rules for URI.ARPA |
| |
|
|
This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone. |
|
| |
| RFC 8959 | The "secret-token" URI Scheme |
| |
|
|
This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens. |
|
| |
| RFC 8960 | A YANG Data Model for MPLS Base |
| |
| Authors: | T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram. |
| Date: | December 2020 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8960 |
|
This document contains a specification of the MPLS base YANG data model. The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS- enabled router. It is expected that other MPLS YANG data models(e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YANG data model. |
|
| |
| RFC 8961 | Requirements for Time-Based Loss Detection |
| |
|
|
Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet"lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high- level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. |
|
| |
| RFC 8962 | Establishing the Protocol Police |
| |
| Authors: | G. Grover, N. ten Oever, C. Cath, S. Sahib. |
| Date: | 1 April 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8962 |
|
One mantra of the IETF is, "We are not the Protocol Police."However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.
This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to theProtocol Police. |
|
| |
| RFC 8963 | Evaluation of a Sample of RFCs Produced in 2018 |
| |
|
|
This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the IndependentStream, from the first individual draft to the publication of theRFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.
We also measure the number of citations of the chosen RFC usingSemantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that. |
|
| |
| RFC 8964 | Deterministic Networking (DetNet) Data Plane: MPLS |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8964 |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS TrafficEngineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework. |
|
| |
| RFC 8965 | Applicability of the Babel Routing Protocol |
| |
|
|
Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. |
|
| |
| RFC 8966 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557. |
|
| |
| RFC 8967 | MAC Authentication for the Babel Routing Protocol |
| |
|
|
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance.This document obsoletes RFC 7298. |
|
| |
| RFC 8968 | Babel Routing Protocol over Datagram Transport Layer Security |
| |
| Authors: | A. Décimo, D. Schinazi, J. Chroboczek. |
| Date: | January 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8968 |
|
The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties using Datagram Transport Layer Security (DTLS). |
|
| |
| RFC 8969 | A Framework for Automating Service and Network Management with YANG |
| |
| Authors: | Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng. |
| Date: | January 2021 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8969 |
|
Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.
This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. |
|
| |
| RFC 8970 | IMAP4 Extension: Message Preview Generation |
| |
|
|
This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message. |
|
| |
| RFC 8971 | Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) |
| |
| Authors: | S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda. |
| Date: | December 2020 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8971 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Virtual eXtensible LocalArea Network (VXLAN) tunnels used to form an overlay network. |
|
| |
| RFC 8972 | Simple Two-Way Active Measurement Protocol Optional Extensions |
| |
| Authors: | G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini. |
| Date: | January 2021 |
| Formats: | txt html json pdf xml |
| Updates: | RFC 8762 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8972 |
|
This document describes optional extensions to Simple Two-way ActiveMeasurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762. |
|
| |
| RFC 8973 | DDoS Open Threat Signaling (DOTS) Agent Discovery |
| |
| Authors: | M. Boucadair, T. Reddy.K. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8973 |
|
This document specifies mechanisms to configure DDoS Open ThreatSignaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed. |
|
| |
| RFC 8974 | Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) |
| |
|
|
This document provides considerations for alleviating ConstrainedApplication Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.
This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header. |
|
| |
| RFC 8975 | Network Coding for Satellite Systems |
| |
| Authors: | N. Kuhn, Ed., E. Lochin, Ed.. |
| Date: | January 2021 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8975 |
|
This document is a product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406).
The objective is to contribute to a larger deployment of NetworkCoding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems. |
|
| |
| RFC 8976 | Message Digest for DNS Zones |
| |
| Authors: | D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker. |
| Date: | February 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8976 |
|
This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest.The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets(DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation.However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. |
|
| |
| RFC 8977 | Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging |
| |
| Authors: | M. Loffredo, M. Martinelli, S. Hollenbeck. |
| Date: | January 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8977 |
|
The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets. This omission can lead to unpredictable server processing of queries and client processing of responses. This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses. This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets. |
|
| |
| RFC 8978 | Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events |
| |
| Authors: | F. Gont, J. Žorž, R. Patterson. |
| Date: | March 2021 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8978 |
|
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed. |
|
| |
| RFC 8979 | Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) |
| |
| Authors: | B. Sarikaya, D. von Hugo, M. Boucadair. |
| Date: | February 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8979 |
|
This document defines the Subscriber and Performance PolicyIdentifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriateService Function Chaining (SFC) operations. The structure of eachContext Header and their use and processing by NSH-aware nodes are described. |
|
| |
| RFC 8980 | Report from the IAB Workshop on Design Expectations vs |
| |
| Authors: | Deployment Reality in Protocol Development. J. Arkko, T. Hardie. |
| Date: | February 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8980 |
|
The Design Expectations vs. Deployment Reality in ProtocolDevelopment Workshop was convened by the Internet Architecture Board(IAB) in June 2019. This report summarizes the workshop's 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 8981 | Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
| Authors: | F. Gont, S. Krishnan, T. Narten, R. Draves. |
| Date: | February 2021 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 4941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8981 |
|
This document describes an extension to IPv6 Stateless AddressAutoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. |
|
| |
| RFC 8982 | Registration Data Access Protocol (RDAP) Partial Response |
| |
| Authors: | M. Loffredo, M. Martinelli. |
| Date: | February 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8982 |
|
The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses. Servers will only return full responses that include all of the information that a client is authorized to receive. A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers. This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response. |
|
| |
| RFC 8983 | Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence |
| |
|
|
This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.
This document updates RFC 7296. |
|
| |
| RFC 8984 | JSCalendar: A JSON Representation of Calendar Data |
| |
|
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based onJSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
|
| |
| RFC 8985 | The RACK-TLP Loss Detection Algorithm for TCP |
| |
| Authors: | Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha. |
| Date: | February 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8985 |
|
This document presents the RACK-TLP loss detection algorithm for TCP.RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment(RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach. |
|
| |
| RFC 8986 | Segment Routing over IPv6 (SRv6) Network Programming |
| |
| Authors: | C. Filsfils, Ed., P. Camarillo, Ed., J. Leddy, D. Voyer, S. Matsushima, Z. Li. |
| Date: | February 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8986 |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.
This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. |
|
| |
| RFC 8987 | DHCPv6 Prefix Delegating Relay Requirements |
| |
| Authors: | I. Farrer, N. Kottapalli, M. Hunek, R. Patterson. |
| Date: | February 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8987 |
|
This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.
It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks. |
|
| |
| RFC 8989 | Additional Criteria for Nominating Committee Eligibility |
| |
|
|
This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713. |
|
| |
| RFC 8990 | GeneRic Autonomic Signaling Protocol (GRASP) |
| |
| Authors: | C. Bormann, B. Carpenter, Ed., B. Liu, Ed.. |
| Date: | May 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8990 |
|
This document specifies the GeneRic Autonomic Signaling Protocol(GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. |
|
| |
| RFC 8991 | GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) |
| |
| Authors: | B. Carpenter, B. Liu, Ed., W. Wang, X. Gong. |
| Date: | May 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8991 |
|
This document is a conceptual outline of an Application ProgrammingInterface (API) for the GeneRic Autonomic Signaling Protocol (GRASP).Such an API is needed for Autonomic Service Agents (ASAs) calling theGRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems. |
|
| |
| RFC 8992 | Autonomic IPv6 Edge Prefix Management in Large-Scale Networks |
| |
| Authors: | S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun. |
| Date: | May 2021 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8992 |
|
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure. |
|
| |
| RFC 8993 | A Reference Model for Autonomic Networking |
| |
| Authors: | M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre. |
| Date: | May 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8993 |
|
This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. |
|
| |
| RFC 8994 | An Autonomic Control Plane (ACP) |
| |
| Authors: | T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason. |
| Date: | May 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8994 |
|
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the"Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. |
|
| |
| RFC 8995 | Bootstrapping Remote Secure Key Infrastructure (BRSKI) |
| |
| Authors: | M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen. |
| Date: | May 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8995 |
|
This document specifies automated bootstrapping of an AutonomicControl Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process theBootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. |
|
| |
| RFC 8996 | Deprecating TLS 1.0 and TLS 1.1 |
| |
| Authors: | K. Moriarty, S. Farrell. |
| Date: | March 2021 |
| Formats: | txt html json pdf xml |
| Obsoletes: | RFC 5469, RFC 7507 |
| Updates: | RFC 3261, RFC 3329, RFC 3436, RFC 3470, RFC 3501, RFC 3552, RFC 3568, RFC 3656, RFC 3749, RFC 3767, RFC 3856, RFC 3871, RFC 3887, RFC 3903, RFC 3943, RFC 3983, RFC 4097, RFC 4111, RFC 4162, RFC 4168, RFC 4217, RFC 4235, RFC 4261, RFC 4279, RFC 4497, RFC 4513, RFC 4531, RFC 4540, RFC 4582, RFC 4616, RFC 4642, RFC 4680, RFC 4681, RFC 4712, RFC 4732, RFC 4743, RFC 4744, RFC 4785, RFC 4791, RFC 4823, RFC 4851, RFC 4964, RFC 4975, RFC 4976, RFC 4992, RFC 5018, RFC 5019, RFC 5023, RFC 5024, RFC 5049, RFC 5054, RFC 5091, RFC 5158, RFC 5216, RFC 5238, RFC 5263, RFC 5281, RFC 5364, RFC 5415, RFC 5422, RFC 5456, RFC 5734, RFC 5878, RFC 5953, RFC 6012, RFC 6042, RFC 6083, RFC 6084, RFC 6176, RFC 6347, RFC 6353, RFC 6367, RFC 6460, RFC 6614, RFC 6739, RFC 6749, RFC 6750, RFC 7030, RFC 7465, RFC 7525, RFC 7562, RFC 7568, RFC 8261, RFC 8422 |
| Also: | BCP 0195 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8996 |
|
This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions.TLS version 1.2 became the recommended version for IETF protocols in2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions.Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.
This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC4347) but not DTLS version 1.2, and there is no DTLS version 1.1.
This document updates many RFCs that normatively refer to TLS version1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. |
|
| |
| RFC 8997 | Deprecation of TLS 1.1 for Email Submission and Access |
| |
|
|
This specification updates the current recommendation for the use of the Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a MailSubmission Server or Mail Access Server. This document updates RFC8314. |
|
| |
| RFC 8998 | ShangMi (SM) Cipher Suites for TLS 1.3 |
| |
|
|
This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3.
The use of these algorithms with TLS 1.3 is not endorsed by the IETF.The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. |
|
| |
| RFC 8999 | Version-Independent Properties of QUIC |
| |
|
|
This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. |
|
