Internet Documents

RFCs 8600 - 8699s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
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 json pdf
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
 
Authors:M. Kucherawy.
Date:May 2019
Formats:txt json pdf
Obsoletes:RFC 7601
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8601
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
 
Authors:J. Arkko, T. Hardie.
Date:July 2019
Formats:txt json pdf
Updates:RFC 3219
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8602
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 pdf
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 json pdf
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 json pdf
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
 
Authors:R. Jesske.
Date:June 2019
Formats:txt json pdf
Updates:RFC 3326
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8606
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 pdf
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
 
Authors:S. Turner, O. Borchert.
Date:June 2019
Formats:txt json pdf
Obsoletes:RFC 8208
Updates:RFC 7935
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8608
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 json pdf
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 json pdf
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 json pdf
Updates:RFC 8029
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 pdf
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 pdf
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 json pdf
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)
 
Authors:M. Nottingham.
Date:May 2019
Formats:txt json pdf
Obsoletes:RFC 5785
Updates:RFC 7230, RFC 7595
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8615
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
 
Authors:J. Levine.
Date:June 2019
Formats:txt json pdf
Updates:RFC 6376, RFC 7208, RFC 7489
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8616
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 pdf
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 json pdf
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 json pdf
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)
 
Authors:N. Jenkins, C. Newman.
Date:July 2019
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8620
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
 
Authors:N. Jenkins, C. Newman.
Date:August 2019
Formats:txt json pdf
Updates:RFC 5788
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8621
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
 
Authors:R. Bless.
Date:June 2019
Formats:txt json pdf
Obsoletes:RFC 3662
Updates:RFC 4594, RFC 8325
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8622
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 pdf
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
 
Authors:P. Wouters, O. Sury.
Date:June 2019
Formats:txt json pdf
Obsoletes:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8624
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 json pdf
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 pdf
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 json pdf
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 json pdf
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 json pdf
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 json pdf
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 pdf
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 pdf
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 json pdf
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 json pdf
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 pdf
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 pdf
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 json pdf
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 json pdf
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 pdf
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 pdf
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 json pdf
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 json pdf
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 pdf
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 pdf
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.