| |
| 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 html json |
| 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 html json |
| Updated by: | RFC 9272 |
| 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 html |
| Updated by: | RFC 9256 |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 |
| |
|
|
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 html json |
| Updated by: | RFC 8664 |
| 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 html json |
| 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 html json |
| Updated by: | RFC 9295 |
| 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 html json |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 html |
| Obsoletes: | RFC 4492 |
| Updated by: | RFC 8996 |
| 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 html |
| 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 html json |
| 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 |
| |
|
|
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 html |
| 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 html |
| 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 html json |
| Updated by: | RFC 9100 |
| 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 |
| |
|
|
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 html json |
| 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 html json |
| 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 html |
| 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 html |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 html |
| 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 |
| |
|
|
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 html json |
| 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 html json |
| 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 html |
| Updated by: | RFC 9272 |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html |
| 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 |
| |
|
|
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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 html |
| 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 html |
| 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 html |
| 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 html json |
| 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) |
| |
|
|
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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 html |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 html |
| 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 html json |
| 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 html json |
| 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 html |
| Obsoleted by: | RFC 8878 |
| 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 html |
| 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 html |
| 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) |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 8489 | Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews. |
| Date: | February 2020 |
| Formats: | txt json html |
| Obsoletes: | RFC 5389 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8489 |
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings.STUN works with many existing NATs and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution.
This document obsoletes RFC 5389. |
|
| |
| RFC 8490 | DNS Stateful Operations |
| |
| Authors: | R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri. |
| Date: | March 2019 |
| Formats: | txt json html |
| 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 html |
| 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 html json |
| 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 html json |
| 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 html |
| 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 html |
| 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 html json |
| 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 html json |
| 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) |
| |
|
|
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 |
| |
|
|
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. |
|
