Internet Documents

RFCs 8400 - 8499s

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

 
RFC 8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
 
Authors:H. Chen, A. Liu, T. Saad, F. Xu, L. Huang.
Date:June 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8400
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP)Traffic Engineered (TE) Label Switched Path (LSP).
 
RFC 8401 Bit Index Explicit Replication (BIER) Support via IS-IS
 
Authors:L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang.
Date:June 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8401
This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.
 
RFC 8402 Segment Routing Architecture
 
Authors:C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir.
Date:July 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8402
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. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by theDestination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

 
RFC 8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System
 
Authors:R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar.
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8403
This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations,Administration, and Maintenance (OAM) measurements while enabling newOAM features.
 
RFC 8404 Effects of Pervasive Encryption on Operators
 
Authors:K. Moriarty, Ed., A. Morton, Ed..
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8404
Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developingIETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.
 
RFC 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
 
Authors:B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers.
Date:June 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8405
This document defines a standard algorithm to temporarily postpone or"back off" link-state IGP Shortest Path First (SPF) computations.This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.

Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally closeIGP events.

 
RFC 8406 Taxonomy of Coding Techniques for Efficient Network Communications
 
Authors:B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar.
Date:June 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8406
This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents onNetwork Coding. This document is the product of the Coding forEfficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the ReliableMulticast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.
 
RFC 8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
 
Authors:A. Bierman.
Date:October 2018
Formats:txt json pdf
Obsoletes:RFC 6087
Also:BCP 0216
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8407
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol(NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.
 
RFC 8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
 
Authors:S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick.
Date:July 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8408
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, otherTE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol(PCEP) to allow support for different path setup methods over a givenPCEP session.
 
RFC 8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types
 
Authors:I. Young, Ed., L. Johansson, S. Cantor.
Date:August 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8409
This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.

This document is a product of the working group process of theResearch and Education FEDerations (REFEDS) group.

 
RFC 8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
 
Authors:S. Josefsson, J. Schaad.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8410
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 andEd448. The key agreement algorithms covered are X25519 and X448.The encoding for public key, private key, and Edwards-curve DigitalSignature Algorithm (EdDSA) structures is provided.
 
RFC 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range
 
Authors:J. Schaad, R. Andrews.
Date:August 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8411
When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.
 
RFC 8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC
 
Authors:C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay.
Date:July 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8412
This document extends "PA-TNC: A Posture Attribute (PA) ProtocolCompatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA):Overview and Requirements" (RFC 5209).
 
RFC 8413 Framework for Scheduled Use of Resources
 
Authors:Y. Zhuang, Q. Wu, H. Chen, A. Farrel.
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8413
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
 
RFC 8414 OAuth 2.0 Authorization Server Metadata
 
Authors:M. Jones, N. Sakimura, J. Bradley.
Date:June 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8414
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with anOAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
 
RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
 
Authors:T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters.
Date:November 2018
Formats:txt json pdf
Obsoletes:RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8415
This document describes the Dynamic Host Configuration Protocol forIPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes.Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).

This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083,RFC 7283, and RFC 7550.

 
RFC 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM)
 
Authors:D. Ma, D. Mandelberg, T. Bruijnzeels.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8416
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of InternetNumber Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers(ISPs), can use the RPKI to validate BGP route origin assertions.ISPs can also use the RPKI to validate the path of a BGP route.However, ISPs may want to establish a local view of exceptions to theRPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding globalRPKI repository data as needed.
 
RFC 8417 Security Event Token (SET)
 
Authors:P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari.
Date:July 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8417
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSONWeb Token (JWT), which can be optionally signed and/or encrypted.SETs can be distributed via protocols such as HTTP.
 
RFC 8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8418
This document describes the conventions for using the Elliptic CurveDiffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).
 
RFC 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8419
This document specifies the conventions for using the Edwards-curveDigital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.
 
RFC 8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
 
Authors:Y. Nir.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8420
This document describes the use of the Edwards-curve DigitalSignature Algorithm (EdDSA) in the Internet Key Exchange ProtocolVersion 2 (IKEv2).
 
RFC 8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
 
Authors:P. Martinsen, T. Reddy, P. Patil.
Date:July 2018
Formats:txt json pdf
Also:BCP 0217
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8421
This document provides guidelines on how to make InteractiveConnectivity Establishment (ICE) conclude faster in multihomed andIPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).
 
RFC 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
 
Authors:Y. Nir, S. Josefsson, M. Pegourie-Gonnard.
Date:August 2018
Formats:txt json pdf
Obsoletes:RFC 4492
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8422
This document describes key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral EllipticCurve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) andEdwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.

This document obsoletes RFC 4492.

 
RFC 8423 Reclassification of Suite B Documents to Historic Status
 
Authors:R. Housley, L. Zieglar.
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8423
This document reclassifies the RFCs related to the United StatesNational Security Agency (NSA) Suite B cryptographic algorithms asHistoric, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239,6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and5430.
 
RFC 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
 
Authors:H. Chen, Ed., R. Torvi, Ed..
Date:August 2018
Formats:txt json pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8424
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) TrafficEngineered (TE) Label Switched Path (LSP). It extends the FastReroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.
 
RFC 8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
 
Authors:O. Troan.
Date:July 2018
Formats:txt json pdf
Updates:RFC 4861
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8425
The Prefix Information Option (PIO) in the IPv6 Neighbor DiscoveryRouter Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved(Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.
 
RFC 8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
 
Authors:H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan.
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8426
Operators are looking to introduce services over Segment Routing (SR)Label Switched Paths (LSPs) in networks running Resource ReservationProtocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SRLSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network.Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.
 
RFC 8427 Representing DNS Messages in JSON
 
Authors:P. Hoffman.
Date:July 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8427
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.
 
RFC 8428 Sensor Measurement Lists (SenML)
 
Authors:C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8428
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists(SenML). Representations are defined in JavaScript Object Notation(JSON), Concise Binary Object Representation (CBOR), ExtensibleMarkup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
 
RFC 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos
 
Authors:B. Kaduk, M. Short.
Date:October 2018
Formats:txt json pdf
Updates:RFC 3961, RFC 4120
Also:BCP 0218
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8429
The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved toHistoric status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.
 
RFC 8430 RIB Information Model
 
Authors:N. Bahadur, Ed., S. Kini, Ed., J. Medved.
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8430
Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using aRouting Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.
 
RFC 8431 A YANG Data Model for the Routing Information Base (RIB)
 
Authors:L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur.
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8431
This document defines a YANG data model for the Routing InformationBase (RIB) that aligns with the Interface to the Routing System(I2RS) RIB information model.
 
RFC 8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters
 
Authors:J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8432
The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.

This document describes the required characteristics and use cases for control and management of radio link interface parameters using aYANG data model.

The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.

 
RFC 8433 A Simpler Method for Resolving Alert-Info URNs
 
Authors:D. Worley.
Date:August 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8433
The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone(user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.

RFC 7462 describes a non-normative algorithm for signal selection.This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process theURNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.

 
RFC 8434 Requirements for Parallel NFS (pNFS) Layout Types
 
Authors:T. Haynes.
Date:August 2018
Formats:txt json pdf
Updates:RFC 5661
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8434
This document defines the requirements that individual Parallel NFS(pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.
 
RFC 8435 Parallel NFS (pNFS) Flexible File Layout
 
Authors:B. Halevy, T. Haynes.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8435
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.
 
RFC 8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
 
Authors:G. Fairhurst.
Date:August 2018
Formats:txt json pdf
Updates:RFC 2474
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8436
The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. TheInternet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.

This update to RFC 2474 changes the IANA registration policy for Pool3 of the registry (i.e., DSCP values of the form xxxx01) to StandardsAction, i.e., values are assigned through a Standards Track or BestCurrent Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of theDSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

 
RFC 8437 IMAP UNAUTHENTICATE Extension for Connection Reuse
 
Authors:C. Newman.
Date:August 2018
Formats:txt json pdf
Updates:RFC 3501
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8437
This specification extends the Internet Message Access Protocol(IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.
 
RFC 8438 IMAP Extension for STATUS=SIZE
 
Authors:S. Bosch.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8438
This document adds a new capability called "STATUS=SIZE" to theInternet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.
 
RFC 8439 ChaCha20 and Poly1305 for IETF Protocols
 
Authors:Y. Nir, A. Langley.
Date:June 2018
Formats:txt json pdf
Obsoletes:RFC 7539
Status:INFORMATIONAL
DOI:10.17487/RFC 8439
This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data(AEAD) algorithm.

RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the SecurityConsiderations section.

 
RFC 8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
 
Authors:K. Murchison, B. Gondwana.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8440
This document defines an extension to the Internet Message AccessProtocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.
 
RFC 8441 Bootstrapping WebSockets with HTTP/2
 
Authors:P. McManus.
Date:September 2018
Formats:txt json pdf
Updates:RFC 6455
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8441
This document defines a mechanism for running the WebSocket Protocol(RFC 6455) over a single stream of an HTTP/2 connection.
 
RFC 8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
 
Authors:J. Mattsson, D. Migault.
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8442
This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of theDatagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman withPre-Shared Key (ECDHE_PSK) key exchange together with theAuthenticated Encryption with Associated Data (AEAD) algorithmsAES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM andAES-CCM provide encryption and integrity protection.
 
RFC 8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
 
Authors:R. Singh, M. Dolly, S. Das, A. Nguyen.
Date:August 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8443
This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.
 
RFC 8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
 
Authors:P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin.
Date:November 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8444
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). TheBFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in theBIER packet header.

This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.

 
RFC 8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
 
Authors:A. Keranen, C. Holmberg, J. Rosenberg.
Date:July 2018
Formats:txt json pdf
Obsoletes:RFC 5245
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8445
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based communication. This protocol is calledInteractive Connectivity Establishment (ICE). ICE makes use of theSession Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).

This document obsoletes RFC 5245.

 
RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
 
Authors:E. Rescorla.
Date:August 2018
Formats:txt json pdf
Obsoletes:RFC 5077, RFC 5246, RFC 6961
Updates:RFC 5705, RFC 6066
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8446
This document specifies version 1.3 of the Transport Layer Security(TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,5246, and 6961. This document also specifies new requirements forTLS 1.2 implementations.

 
RFC 8447 IANA Registry Updates for TLS and DTLS
 
Authors:J. Salowey, S. Turner.
Date:August 2018
Formats:txt json pdf
Updates:RFC 3749, RFC 4680, RFC 5077, RFC 5246, RFC 5705, RFC 5878, RFC 6520, RFC 7301
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8447
This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.

This document updates the following RFCs: 3749, 5077, 4680, 5246,5705, 5878, 6520, and 7301.

 
RFC 8448 Example Handshake Traces for TLS 1.3
 
Authors:M. Thomson.
Date:January 2019
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8448
This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced.Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.
 
RFC 8449 Record Size Limit Extension for TLS
 
Authors:M. Thomson.
Date:August 2018
Formats:txt json pdf
Updates:RFC 6066
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8449
An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.

This replaces the maximum fragment length extension defined inRFC 6066.

 
RFC 8450 RTP Payload Format for VC-2 High Quality (HQ) Profile
 
Authors:J. Weaver.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8450
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television EngineersStandard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.

The HQ profile of VC-2 is intended for low-latency video compression(with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).

 
RFC 8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API
 
Authors:V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng.
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8451
This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTPControl Protocol (RTCP) Sender Report (SR), Receiver Report (RR), andExtended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.
 
RFC 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
 
Authors:S. Gueron, A. Langley, Y. Lindell.
Date:April 2019
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8452
This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.

This document is the product of the Crypto Forum Research Group.

 
RFC 8453 Framework for Abstraction and Control of TE Networks (ACTN)
 
Authors:D. Ceccarelli, Ed., Y. Lee, Ed..
Date:August 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8453
Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.

Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.

This document provides a framework for Abstraction and Control of TENetworks (ACTN) to support virtual network services and connectivity services.

 
RFC 8454 Information Model for Abstraction and Control of TE Networks (ACTN)
 
Authors:Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon.
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8454
This document provides an information model for Abstraction andControl of TE Networks (ACTN).
 
RFC 8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
 
Authors:V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8455
This document defines terminology for benchmarking a Software-DefinedNetworking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.
 
RFC 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance
 
Authors:V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8456
This document defines methodologies for benchmarking the control- plane performance of Software-Defined Networking (SDN) Controllers.The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.
 
RFC 8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute
 
Authors:B. Leiba, Ed..
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8457
RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute,"\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword,"$Important", and registers it in the registry defined in RFC 5788.
 
RFC 8458 Using National Bibliography Numbers as Uniform Resource Names
 
Authors:J. Hakala.
Date:October 2018
Formats:txt json pdf
Obsoletes:RFC 3188
Status:INFORMATIONAL
DOI:10.17487/RFC 8458
National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such asInternational Standard Book Number (ISBN).

A Uniform Resource Name (URN) namespace for NBNs was established in2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.

This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration(version 4) compliant to RFC 8141 is included.

 
RFC 8459 Hierarchical Service Function Chaining (hSFC)
 
Authors:D. Dolson, S. Homma, D. Lopez, M. Boucadair.
Date:September 2018
Formats:txt json pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8459
Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.

The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

 
RFC 8460 SMTP TLS Reporting
 
Authors:D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher.
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8460
A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA StrictTransport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.
 
RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)
 
Authors:D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones.
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8461
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receiveTransport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
 
RFC 8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
 
Authors:N. Rooney, S. Dawkins, Ed..
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8462
The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World(MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.

The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and ContentDelivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.

A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

 
RFC 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
 
Authors:J. Levine.
Date:September 2018
Formats:txt json pdf
Updates:RFC 6376
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8463
This document adds a new signing algorithm, Ed25519-SHA256, to"DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.
 
RFC 8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)
 
Authors:R. Atarius.
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8464
This document defines a Uniform Resource Name (URN) namespace for theThird Generation Partnership Project 2 (3GPP2) and a NamespaceSpecific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment(e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.
 
RFC 8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID
 
Authors:R. Atarius, Ed..
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8465
This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the MobileEquipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance"Contact header field parameter for outbound behavior.
 
RFC 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
 
Authors:B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8466
This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.

The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipointVirtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border GatewayProtocol (BGP) as described in RFCs 4761 and 6624.

The YANG data model defined in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342.

 
RFC 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0))
 
Authors:A. Mayrhofer.
Date:October 2018
Formats:txt json pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8467
RFC 7830 specifies the "Padding" option for Extension Mechanisms forDNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.
 
RFC 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework
 
Authors:A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde.
Date:November 2018
Formats:txt json pdf
Updates:RFC 2330
Status:INFORMATIONAL
DOI:10.17487/RFC 8468
This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework.Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks(6LoWPAN) are considered and excluded from the standard-formed packet evaluation.
 
RFC 8469 Recommendation to Use the Ethernet Control Word
 
Authors:S. Bryant, A. Malis, I. Bagdonas.
Date:November 2018
Formats:txt json pdf
Updates:RFC 4448
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8469
The pseudowire (PW) encapsulation of Ethernet, as defined inRFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR).This may lead to the selection of the wrong equal-cost multipath(ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.

This document updates RFC 4448.

 
RFC 8470 Using Early Data in HTTP
 
Authors:M. Thomson, M. Nottingham, W. Tarreau.
Date:September 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8470
Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.
 
RFC 8471 The Token Binding Protocol Version 1.0
 
Authors:A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8471
This document specifies version 1.0 of the Token Binding protocol.The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, theToken Binding identifiers are only conveyed over TLS and can be reset by the user at any time.
 
RFC 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
 
Authors:A. Popov, Ed., M. Nystroem, D. Balfanz.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8472
This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.
 
RFC 8473 Token Binding over HTTP
 
Authors:A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8473
This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.

This document is a companion document to "The Token Binding ProtocolVersion 1.0" (RFC 8471).

 
RFC 8474 IMAP Extension for Object Identifiers
 
Authors:B. Gondwana, Ed..
Date:September 2018
Formats:txt json pdf
Updates:RFC 3501
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8474
This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.
 
RFC 8475 Using Conditional Router Advertisements for Enterprise Multihoming
 
Authors:J. Linkova, M. Stucchi.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8475
This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation:Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality(Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has twoInternet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.
 
RFC 8476 Signaling Maximum SID Depth (MSD) Using OSPF
 
Authors:J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak.
Date:December 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8476
This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths(MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.
 
RFC 8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
 
Authors:J. Jimenez, H. Tschofenig, D. Thaler.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8477
This document provides a summary of the "Workshop on Internet ofThings (IoT) Semantic Interoperability (IOTSI)", which took place inSanta Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
 
RFC 8478 Zstandard Compression and the application/zstd Media Type
 
Authors:Y. Collet, M. Kucherawy, Ed..
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8478
Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet MailExtensions (MIME).

Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

 
RFC 8479 Storing Validation Parameters in PKCS#8
 
Authors:N. Mavrogiannopoulos.
Date:September 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8479
This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information SyntaxSpecification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-KeyInformation Syntax Specification as defined in RFC 5958.

The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.

 
RFC 8480 6TiSCH Operation Sublayer (6top) Protocol (6P)
 
Authors:Q. Wang, Ed., X. Vilajosana, T. Watteyne.
Date:November 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8480
This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e"(6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.
 
RFC 8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)
 
Authors:R. Bush.
Date:September 2018
Formats:txt json pdf
Updates:RFC 6811
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8481
Deployment of BGP origin validation based on Resource Public KeyInfrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration.This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.
 
RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
 
Authors:J. Abley, O. Gudmundsson, M. Majkowski, E. Hunt.
Date:January 2019
Formats:txt json pdf
Updates:RFC 1034, RFC 1035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8482
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.

This document updates RFCs 1034 and 1035.

 
RFC 8483 Yeti DNS Testbed
 
Authors:L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8483
Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet'sDomain Name System is designed and built).
 
RFC 8484 DNS Queries over HTTPS (DoH)
 
Authors:P. Hoffman, P. McManus.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8484
This document defines a protocol for sending DNS queries and gettingDNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.
 
RFC 8485 Vectors of Trust
 
Authors:J. Richer, Ed., L. Johansson.
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8485
This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.
 
RFC 8486 Ambisonics in an Ogg Opus Container
 
Authors:J. Skoglund, M. Graczyk.
Date:October 2018
Formats:txt json pdf
Updates:RFC 7845
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8486
This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.
 
RFC 8487 Mtrace Version 2: Traceroute Facility for IP Multicast
 
Authors:H. Asaeda, K. Meyer, W. Lee. Ed..
Date:October 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8487
This document describes the IP multicast traceroute facility, namedMtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.
 
RFC 8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation
 
Authors:O. Muravskiy, T. Bruijnzeels.
Date:December 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8488
This document describes an approach to validating the content of theResource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.
 
RFC 8490 DNS Stateful Operations
 
Authors:R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri.
Date:March 2019
Formats:txt json pdf
Updates:RFC 1035, RFC 7766
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8490
This document defines a new DNS OPCODE for DNS Stateful Operations(DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a newDNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.
 
RFC 8491 Signaling Maximum SID Depth (MSD) Using IS-IS
 
Authors:J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg.
Date:November 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8491
This document defines a way for an Intermediate System toIntermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type ofMSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.
 
RFC 8492 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
Authors:D. Harkins, Ed..
Date:February 2019
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8492
This memo defines several new ciphersuites for the Transport LayerSecurity (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.
 
RFC 8493 The BagIt File Packaging Format (V1.0)
 
Authors:J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8493
This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A"bag" has just enough structure to enclose descriptive metadata"tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.
 
RFC 8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142
 
Authors:D. Wilson, A. Melnikov, Ed..
Date:November 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8494
Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (MulticastEmail), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP142). MULE enables transfer between Message Transfer Agents (MTAs).It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).

This document explains how MULE can be used in conjunction with SMTP(RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.

This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

 
RFC 8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
 
Authors:J. Gould, K. Feher.
Date:November 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8495
This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and"transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".
 
RFC 8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)
 
Authors:D. York, T. Asveren.
Date:October 2018
Formats:txt json pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8496
This text documents the current usage of P-Charge-Info, an existingSession Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged.This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.
 
RFC 8497 Marking SIP Messages to Be Logged
 
Authors:P. Dawes, C. Arunachalam.
Date:November 2018
Formats:txt json pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8497
SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent(UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.

This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling.Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminatingSIP user agents, even if a session originates and terminates in different networks.

 
RFC 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)
 
Authors:M. Mohali.
Date:February 2019
Formats:txt json pdf
Updates:RFC 5502
Status:INFORMATIONAL
DOI:10.17487/RFC 8498
The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.
 
RFC 8499 DNS Terminology
 
Authors:P. Hoffman, A. Sullivan, K. Fujiwara.
Date:January 2019
Formats:txt json pdf
Obsoletes:RFC 7719
Updates:RFC 2308
Also:BCP 0219
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8499
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in theDNS in a single document.

This document obsoletes RFC 7719 and updates RFC 2308.