RFC Abstracts

RFC8677 - Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework
Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.
RFC8676 - YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.
RFC8675 - A YANG Data Model for Tunnel Interface Types
This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.
RFC8674 - The "safe" HTTP Preference
This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.
RFC8673 - HTTP Random Access and Live Content
To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.
RFC8672 - TLS Server Identity Pinning with Tickets
Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.
RFC8671 - Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.
RFC8670 - BGP Prefix Segment in Large-Scale Data Centers
This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.
RFC8669 - Segment Routing Prefix Segment Identifier Extensions for BGP
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.
RFC8668 - Advertising Layer 2 Bundle Member Link Attributes in IS-IS
There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.
RFC8667 - IS-IS Extensions for Segment Routing
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
RFC8666 - OSPFv3 Extensions for Segment Routing
Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
RFC8665 - OSPF Extensions for Segment Routing
Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
RFC8664 - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing
Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.
RFC8663 - MPLS Segment Routing over IP
MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.
RFC8662 - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol Label Switching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing MPLS.
RFC8661 - Segment Routing MPLS Interworking with LDP
A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain.
RFC8660 - Segment Routing with the MPLS Data Plane
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).
RFC8659 - DNS Certification Authority Authorization (CAA) Resource Record
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.
RFC8658 - RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)
IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.
RFC8657 - Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required.
RFC8656 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
RFC8655 - Deterministic Networking Architecture
This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.
RFC8654 - Extended Message Support for BGP
The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.
RFC8653 - On-Demand Mobility Management
Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept.
RFC8652 - A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.
RFC8651 - Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.
RFC8650 - Dynamic Subscription to YANG Events and Datastores over RESTCONF
This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.
RFC8649 - Hash Of Root Key Certificate Extension
This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.
RFC8645 - Re-keying Mechanisms for Symmetric Keys
A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.
RFC8643 - An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)
Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.
RFC8642 - Policy Behavior for Well-Known BGP Communities
Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.
RFC8641 - Subscription to YANG Notifications for Datastore Updates
This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.
RFC8640 - Dynamic Subscription to YANG Events and Datastores over NETCONF
This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.
RFC8639 - Subscription to YANG Notifications
This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.
RFC8638 - IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks
During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.
RFC8637 - Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
RFC8636 - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.
RFC8635 - Router Keying for BGPsec
BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.
RFC8634 - BGPsec Router Certificate Rollover
Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.
RFC8633 - Network Time Protocol Best Current Practices
The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.
RFC8632 - A YANG Data Model for Alarm Management
This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.
RFC8631 - Link Relation Types for Web Services
Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.
RFC8630 - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.
RFC8629 - Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.
RFC8628 - OAuth 2.0 Device Authorization Grant
The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.
RFC8627 - RTP Payload Format for Flexible Forward Error Correction (FEC)
This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.
RFC8625 - Ethernet Traffic Parameters with Availability Information
A packet-switching network may contain links with variable bandwidths (e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning. This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling. This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.
RFC8624 - Algorithm Implementation Requirements and Usage Guidance for DNSSEC
The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.
RFC8623 - Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.