| |
| RFC 8600 | Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange |
| |
| Authors: | N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8600 |
|
This document describes how to use the Extensible Messaging andPresence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication amongComputer Security Incident Response Teams and associated entities.To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF). |
|
| |
| RFC 8601 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called"Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents(MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.
This document obsoletes RFC 7601. |
|
| |
| RFC 8602 | Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses |
| |
|
|
This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.
This memo updates RFC 3219. |
|
| |
| RFC 8603 | Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | M. Jenkins, L. Zieglar. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8603 |
|
This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Commercial National SecurityAlgorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems that employ such X.509 certificates. US NationalSecurity Systems are described in NIST Special Publication 800-59.It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8604 | Interconnecting Millions of Endpoints with Segment Routing |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8604 |
|
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document. |
|
| |
| RFC 8605 | vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) |
| |
| Authors: | S. Hollenbeck, R. Carney. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8605 |
|
This document defines extensions to the vCard data format for representing and exchanging contact information used to implement theInternet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).The property and parameter defined here are used to add values toRDAP responses that are consistent with ICANN policies. |
|
| |
| RFC 8606 | ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field |
| |
|
|
The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose. |
|
| |
| RFC 8607 | Calendaring Extensions to WebDAV (CalDAV): Managed Attachments |
| |
| Authors: | C. Daboo, A. Quillaud, K. Murchison, Ed.. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8607 |
|
This specification adds an extension to the Calendaring Extensions toWebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.
This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP. |
|
| |
| RFC 8608 | BGPsec Algorithms, Key Formats, and Signature Formats |
| |
|
|
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208("BGPsec Algorithms, Key Formats, and Signature Formats") by addingDocumentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. |
|
| |
| RFC 8609 | Content-Centric Networking (CCNx) Messages in TLV Format |
| |
| Authors: | M. Mosko, I. Solis, C. Wood. |
| Date: | July 2019 |
| Formats: | txt html json |
| Updated by: | RFC 9510 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8609 |
|
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in aTLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review amongICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. |
|
| |
| RFC 8610 | Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures |
| |
| Authors: | H. Birkholz, C. Vigano, C. Bormann. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8610 |
|
This document proposes a notational convention to express ConciseBinary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR orJSON. |
|
| |
| RFC 8611 | Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces |
| |
| Authors: | N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updates: | RFC 8029 |
| Updated by: | RFC 9041 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8611 |
|
This document defines extensions to the MPLS Label Switched Path(LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-CostMultipath (ECMP) over Link Aggregation Group (LAG) interfaces.Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
This document updates RFC 8029. |
|
| |
| RFC 8612 | DDoS Open Threat Signaling (DOTS) Requirements |
| |
| Authors: | A. Mortensen, T. Reddy, R. Moskowitz. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8612 |
|
This document defines the requirements for the Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. |
|
| |
| RFC 8613 | Object Security for Constrained RESTful Environments (OSCORE) |
| |
| Authors: | G. Selander, J. Mattsson, F. Palombini, L. Seitz. |
| Date: | July 2019 |
| Formats: | txt json html |
| Updates: | RFC 7252 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8613 |
|
This document defines Object Security for Constrained RESTfulEnvironments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR ObjectSigning and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP.OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. |
|
| |
| RFC 8614 | Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) |
| |
| Authors: | R. Singh, K. Kompella, S. Palislamovic. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updates: | RFC 4761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8614 |
|
This document updates the meaning of the Control Flags field in the"Layer2 Info Extended Community" used for BGP Virtual Private LANService (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761. |
|
| |
| RFC 8615 | Well-Known Uniform Resource Identifiers (URIs) |
| |
|
|
This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes.
In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. |
|
| |
| RFC 8616 | Email Authentication for Internationalized Mail |
| |
|
|
Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail(DKIM) (RFC 6376), and Domain-based Message Authentication,Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS.In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. |
|
| |
| RFC 8617 | The Authenticated Received Chain (ARC) Protocol |
| |
| Authors: | K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed.. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8617 |
|
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet MailHandlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. |
|
| |
| RFC 8618 | Compacted-DNS (C-DNS): A Format for DNS Packet Capture |
| |
| Authors: | J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8618 |
|
This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the fullDNS message contents along with the most useful transport metadata.It is intended to assist with the development of DNS traffic- monitoring applications. |
|
| |
| RFC 8619 | Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
| |
| Authors: | R. Housley. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8619 |
|
RFC 5869 specifies the HMAC-based Extract-and-Expand Key DerivationFunction (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions. |
|
| |
| RFC 8620 | The JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. |
|
| |
| RFC 8621 | The JSON Meta Application Protocol (JMAP) for Mail |
| |
|
|
This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP).Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. |
|
| |
| RFC 8622 | A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services |
| |
|
|
This document specifies properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB). The primary objective of this LEPHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for thisPHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LEPHB.
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. |
|
| |
| RFC 8623 | Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) |
| |
| Authors: | U. Palle, D. Dhody, Y. Tanaka, V. Beeram. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8623 |
|
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 ElementCommunication Protocol (PCEP) so as to enable the usage of a statefulPCE capability in supporting P2MP TE LSPs. |
|
| |
| RFC 8624 | 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 andDNS 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 obsoletesRFC 6944. |
|
| |
| RFC 8625 | Ethernet Traffic Parameters with Availability Information |
| |
| Authors: | H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8625 |
|
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 inRSVP-TE signaling. This extension can be used to set up a GMPLSLabel Switched Path (LSP) in conjunction with the EthernetSENDER_TSPEC object. |
|
| |
| RFC 8627 | RTP Payload Format for Flexible Forward Error Correction (FEC) |
| |
| Authors: | M. Zanaty, V. Singh, A. Begen, G. Mandyam. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8627 |
|
This document defines new RTP payload formats for the Forward ErrorCorrection (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 "FLEXFEC"), 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. |
|
| |
| RFC 8628 | OAuth 2.0 Device Authorization Grant |
| |
| Authors: | W. Denniss, J. Bradley, M. Jones, H. Tschofenig. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8628 |
|
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. |
|
| |
| RFC 8629 | Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension |
| |
| Authors: | B. Cheng, L. Berger, Ed.. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8629 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems. |
|
| |
| RFC 8630 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels. |
| Date: | August 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 7730 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8630 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) CertificationAuthority (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.
This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform ResourceIdentifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC7230) as the scheme. |
|
| |
| RFC 8631 | Link Relation Types for Web Services |
| |
| Authors: | E. Wilde. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8631 |
|
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. |
|
| |
| RFC 8632 | A YANG Data Model for Alarm Management |
| |
| Authors: | S. Vallin, M. Bjorklund. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8632 |
|
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. |
|
| |
| RFC 8633 | Network Time Protocol Best Current Practices |
| |
| Authors: | D. Reilly, H. Stenn, D. Sibold. |
| Date: | July 2019 |
| Formats: | txt json html |
| Also: | BCP 0223 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8633 |
|
The Network Time Protocol (NTP) is one of the oldest protocols on theInternet 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. |
|
| |
| RFC 8634 | BGPsec Router Certificate Rollover |
| |
| Authors: | B. Weis, R. Gagliano, K. Patel. |
| Date: | August 2019 |
| Formats: | txt html json |
| Also: | BCP 0224 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8634 |
|
Certification Authorities (CAs) within the Resource Public KeyInfrastructure (RPKI) manage BGPsec router certificates as well asRPKI 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. |
|
| |
| RFC 8635 | Router Keying for BGPsec |
| |
| Authors: | R. Bush, S. Turner, K. Patel. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8635 |
|
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. |
|
| |
| RFC 8636 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility |
| |
| Authors: | L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson. |
| Date: | July 2019 |
| Formats: | txt json html |
| Updates: | RFC 4556 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8636 |
|
This document updates the Public Key Cryptography for InitialAuthentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. ThePKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client'sX.509 certificates are made discoverable.
These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms. |
|
| |
| RFC 8637 | Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) |
| |
| Authors: | D. Dhody, Y. Lee, D. Ceccarelli. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8637 |
|
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.
The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. ThePCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path ComputationElement Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN framework. |
|
| |
| RFC 8638 | IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks |
| |
| Authors: | M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8638 |
|
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 anotherIP 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.
This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ.The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario. |
|
| |
| RFC 8639 | Subscription to YANG Notifications |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8639 |
|
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. |
|
| |
| RFC 8640 | Dynamic Subscription to YANG Events and Datastores over NETCONF |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8640 |
|
This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. |
|
| |
| RFC 8641 | Subscription to YANG Notifications for Datastore Updates |
| |
| Authors: | A. Clemm, E. Voit. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8641 |
|
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. |
|
| |
| RFC 8642 | Policy Behavior for Well-Known BGP Communities |
| |
| Authors: | J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar. |
| Date: | August 2019 |
| Formats: | txt html json |
| Updates: | RFC 1997 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8642 |
|
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. |
|
| |
| RFC 8643 | An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) |
| |
| Authors: | A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8643 |
|
Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined inRFC 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. |
|
| |
| RFC 8645 | Re-keying Mechanisms for Symmetric Keys |
| |
| Authors: | S. Smyshlyaev, Ed.. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8645 |
|
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.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 8649 | Hash Of Root Key Certificate Extension |
| |
| Authors: | R. Housley. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8649 |
|
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 CertificationAuthority (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. |
|
| |
| RFC 8650 | Dynamic Subscription to YANG Events and Datastores over RESTCONF |
| |
| Authors: | E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman. |
| Date: | November 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8650 |
|
This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. |
|
| |
| RFC 8651 | Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension |
| |
| Authors: | B. Cheng, D. Wiggins, L. Berger, Ed.. |
| Date: | October 2019 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8651 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. |
|
| |
| RFC 8652 | A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) |
| |
| Authors: | X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter. |
| Date: | November 2019 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8652 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) devices. |
|
| |
| RFC 8653 | On-Demand Mobility Management |
| |
| Authors: | A. Yegin, D. Moses, S. Jeon. |
| Date: | October 2019 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8653 |
|
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. |
|
| |
| RFC 8654 | 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 FamilyIdentifiers (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. |
|
| |
| RFC 8655 | Deterministic Networking Architecture |
| |
| Authors: | N. Finn, P. Thubert, B. Varga, J. Farkas. |
| Date: | October 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8655 |
|
This document provides the overall architecture for DeterministicNetworking (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. |
|
| |
| RFC 8656 | 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 "TraversalUsing 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.
The TURN protocol was designed to be used as part of the InteractiveConnectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.
This document obsoletes RFCs 5766 and 6156. |
|
| |
| RFC 8657 | 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 theAutomatic Certificate Management Environment (ACME) protocol to be required. |
|
| |
| RFC 8658 | RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P) |
| |
| Authors: | S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed.. |
| Date: | November 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8658 |
|
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 forLightweight 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 anAuthentication, 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.
This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. |
|
| |
| RFC 8659 | DNS Certification Authority Authorization (CAA) Resource Record |
| |
| Authors: | P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews. |
| Date: | November 2019 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 6844 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8659 |
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (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.
This document obsoletes RFC 6844. |
|
| |
| RFC 8660 | Segment Routing with the MPLS Data Plane |
| |
| Authors: | A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8660 |
|
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). |
|
| |
| RFC 8661 | Segment Routing MPLS Interworking with LDP |
| |
| Authors: | A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski. |
| Date: | December 2019 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8661 |
|
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 theSR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. |
|
| |
| RFC 8662 | Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels |
| |
| Authors: | S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura. |
| Date: | December 2019 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8662 |
|
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 LabelSwitching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes howELs are to be applied to Segment Routing MPLS. |
|
| |
| RFC 8663 | MPLS Segment Routing over IP |
| |
| Authors: | X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li. |
| Date: | December 2019 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8663 |
|
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.
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use ofSR-MPLS label stacks and IP encapsulation/tunneling such as MPLS- over-UDP as defined in RFC 7510. |
|
| |
| RFC 8664 | Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing |
| |
| Authors: | S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick. |
| Date: | December 2019 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 8408 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8664 |
|
Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP orRSVP-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 ComputationElement Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as aPath Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.
This document updates RFC 8408. |
|
| |
| RFC 8665 | OSPF Extensions for Segment Routing |
| |
| Authors: | P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura. |
| Date: | December 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8665 |
|
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).
This document describes the OSPFv2 extensions required for SegmentRouting. |
|
| |
| RFC 8666 | OSPFv3 Extensions for Segment Routing |
| |
| Authors: | P. Psenak, Ed., S. Previdi, Ed.. |
| Date: | December 2019 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8666 |
|
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).
This document describes the OSPFv3 extensions required for SegmentRouting with the MPLS data plane. |
|
| |
| RFC 8667 | IS-IS Extensions for Segment Routing |
| |
| Authors: | S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene. |
| Date: | December 2019 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8667 |
|
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).
This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. |
|
| |
| RFC 8668 | Advertising Layer 2 Bundle Member Link Attributes in IS-IS |
| |
| Authors: | L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries. |
| Date: | December 2019 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8668 |
|
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 Layer3 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.
This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. |
|
| |
| RFC 8669 | Segment Routing Prefix Segment Identifier Extensions for BGP |
| |
| Authors: | S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8669 |
|
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.
This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGPPrefix-SIDs) and the specification for SR-MPLS SIDs. |
|
| |
| RFC 8670 | BGP Prefix Segment in Large-Scale Data Centers |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov. |
| Date: | December 2019 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8670 |
|
This document describes the motivation for, and benefits of, applyingSegment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both theMPLS and IPv6 data planes. |
|
| |
| RFC 8671 | Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) |
| |
| Authors: | T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang. |
| Date: | November 2019 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 7854 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8671 |
|
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC7854) 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. |
|
| |
| RFC 8672 | 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.
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required. |
|
| |
| RFC 8673 | HTTP Random Access and Live Content |
| |
| Authors: | C. Pratt, D. Thakore, B. Stark. |
| Date: | November 2019 |
| Formats: | txt html json xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8673 |
|
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. |
|
| |
| RFC 8674 | 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.
This specification does not define a precise semantic for "safe".Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.
Support for this preference by clients and servers is optional. |
|
| |
| RFC 8675 | A YANG Data Model for Tunnel Interface Types |
| |
| Authors: | M. Boucadair, I. Farrer, R. Asati. |
| Date: | November 2019 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8675 |
|
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.
Tunnel type values are not directly added to the Tunnel InterfaceTypes YANG module; they must instead be added to the "tunnelType"IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.
Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed. |
|
| |
| RFC 8676 | YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires |
| |
| Authors: | I. Farrer, Ed., M. Boucadair, Ed.. |
| Date: | November 2019 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8676 |
|
This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and CustomerPremises Equipment for the Lightweight 4over6, Mapping of Address andPort with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. |
|
| |
| RFC 8677 | Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework |
| |
| Authors: | D. Trossen, D. Purkayastha, A. Rahman. |
| Date: | November 2019 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8677 |
|
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 ServiceFunction 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 differentIP 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.
This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that theSFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers. |
|
| |
| RFC 8678 | Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions |
| |
| Authors: | F. Baker, C. Bowers, J. Linkova. |
| Date: | December 2019 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8678 |
|
Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.
This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies.It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator. |
|
| |
| RFC 8679 | MPLS Egress Protection Framework |
| |
| Authors: | Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen. |
| Date: | December 2019 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8679 |
|
This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure. |
|
| |
| RFC 8680 | Forward Error Correction (FEC) Framework Extension to Sliding Window Codes |
| |
|
|
RFC 6363 describes a framework for using Forward Error Correction(FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. |
|
| |
| RFC 8681 | Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME |
| |
|
|
This document describes two fully specified Forward ErasureCorrection (FEC) Schemes for Sliding Window Random Linear Codes(RLC), one for RLC over the Galois Field (a.k.a., Finite Field)GF(2), a second one for RLC over the Galois Field GF(2^(8)), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes. These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real- time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities. |
|
| |
| RFC 8682 | TinyMT32 Pseudorandom Number Generator (PRNG) |
| |
| Authors: | M. Saito, M. Matsumoto, V. Roca, Ed., E. Baccelli. |
| Date: | January 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8682 |
|
This document describes the TinyMT32 Pseudorandom Number Generator(PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller LinearCongruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications. |
|
| |
| RFC 8683 | Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks |
| |
|
|
This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadbandISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications. |
|
| |
| RFC 8684 | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch. |
| Date: | March 2020 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 6824 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8684 |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.
This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. |
|
| |
| RFC 8685 | Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture |
| |
| Authors: | F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King. |
| Date: | December 2019 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8685 |
|
The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.
This document defines extensions to the Path Computation ElementCommunication Protocol (PCEP) to support H-PCE procedures. |
|
| |
| RFC 8686 | Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery |
| |
| Authors: | S. Kiesel, M. Stiemerling. |
| Date: | February 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8686 |
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before anALTO client can ask for guidance, it needs to discover one or moreALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.
Technically, the procedure specified in this document takes oneIP address or prefix and a U-NAPTR Service Parameter (typically,"ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix. |
|
| |
| RFC 8687 | OSPF Routing with Cross-Address Family Traffic Engineering Tunnels |
| |
|
|
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label SwitchedPath (LSP) infrastructure may be duplicated, even if the destinationIPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information.
This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses. |
|
| |
| RFC 8688 | A Session Initiation Protocol (SIP) Response Code for Rejected Calls |
| |
| Authors: | E.W. Burger, B. Nagda. |
| Date: | December 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8688 |
|
This document defines the 608 (Rejected) Session Initiation Protocol(SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. |
|
| |
| RFC 8689 | SMTP Require TLS Option |
| |
|
|
The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-BasedAuthentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant. |
|
| |
| RFC 8690 | Clarification of Segment ID Sub-TLV Length for RFC 8287 |
| |
| Authors: | N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein. |
| Date: | December 2019 |
| Formats: | txt json html xml pdf |
| Updates: | RFC 8287 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8690 |
|
RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers(SIDs) with the MPLS data plane. RFC 8287 proposes three TargetForwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.
This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287. |
|
| |
| RFC 8691 | Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 |
| |
| Authors: | N. Benamar, J. Härri, J. Lee, T. Ernst. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8691 |
|
This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a singleIEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work. |
|
| |
| RFC 8692 | Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs |
| |
|
|
Digital signatures are used to sign messages, X.509 certificates, andCertificate Revocation Lists (CRLs). This document updates the"Algorithms and Identifiers for the Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature andElliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described. |
|
| |
| RFC 8693 | OAuth 2.0 Token Exchange |
| |
| Authors: | M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore. |
| Date: | January 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8693 |
|
This specification defines a protocol for an HTTP- and JSON-basedSecurity Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. |
|
| |
| RFC 8694 | Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering |
| |
|
|
The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS)Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic-Engineered (TE) networks.
This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. |
|
| |
| RFC 8695 | A YANG Data Model for the Routing Information Protocol (RIP) |
| |
| Authors: | X. Liu, P. Sarda, V. Choudhary. |
| Date: | February 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8695 |
|
This document describes a data model for the management of theRouting Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA). |
|
| |
| RFC 8696 | Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) |
| |
|
|
The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. |
|
| |
| RFC 8697 | Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) |
| |
| Authors: | I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka. |
| Date: | January 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8697 |
|
This document introduces a generic mechanism to create a grouping ofLabel Switched Paths (LSPs) in the context of a Path ComputationElement (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes(such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. |
|
| |
| RFC 8698 | Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media |
| |
| Authors: | X. Zhu, R. Pan, M. Ramalho, S. Mena. |
| Date: | February 2020 |
| Formats: | txt json xml html pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8698 |
|
This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. |
|
| |
| RFC 8699 | Coupled Congestion Control for RTP Media |
| |
| Authors: | S. Islam, M. Welzl, S. Gjessing. |
| Date: | January 2020 |
| Formats: | txt json xml html pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8699 |
|
When multiple congestion-controlled Real-time Transport Protocol(RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms. |
|
