| |
| RFC 8200 | Internet Protocol, Version 6 (IPv6) Specification |
| |
|
|
This document specifies version 6 of the Internet Protocol (IPv6).It obsoletes RFC 2460. |
|
| |
| RFC 8201 | Path MTU Discovery for IP version 6 |
| |
|
|
This document describes Path MTU Discovery (PMTUD) for IP version 6.It is largely derived from RFC 1191, which describes Path MTUDiscovery for IP version 4. It obsoletes RFC 1981. |
|
| |
| RFC 8202 | IS-IS Multi-Instance |
| |
| Authors: | L. Ginsberg, S. Previdi, W. Henderickx. |
| Date: | June 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 6822 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8202 |
|
This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.
This document obsoletes RFC 6822. |
|
| |
| RFC 8203 | BGP Administrative Shutdown Communication |
| |
|
|
This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. |
|
| |
| RFC 8204 | Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) |
| |
| Authors: | M. Tahhan, B. O'Mahony, A. Morton. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8204 |
|
This memo describes the contributions of the Open Platform for NFV(OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in theIETF and references existing literature. The BenchmarkingMethodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the"telco" infrastructure. |
|
| |
| RFC 8205 | BGPsec Protocol Specification |
| |
| Authors: | M. Lepinski, Ed., K. Sriram, Ed.. |
| Date: | September 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8206 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8205 |
|
This document describes BGPsec, an extension to the Border GatewayProtocol (BGP) that provides security for the path of AutonomousSystems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates theUPDATE message. The digital signatures provide confidence that everyAS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. |
|
| |
| RFC 8206 | BGPsec Considerations for Autonomous System (AS) Migration |
| |
| Authors: | W. George, S. Murphy. |
| Date: | September 2017 |
| Formats: | txt json html |
| Updates: | RFC 8205 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8206 |
|
This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol. |
|
| |
| RFC 8207 | BGPsec Operational Considerations |
| |
|
|
Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed. |
|
| |
| RFC 8208 | BGPsec Algorithms, Key Formats, and Signature Formats |
| |
|
|
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. |
|
| |
| RFC 8209 | A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests |
| |
| Authors: | M. Reynolds, S. Turner, S. Kent. |
| Date: | September 2017 |
| Formats: | txt html json |
| Updates: | RFC 6487 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8209 |
|
This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the BorderGateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in theInternet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure(RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends theRPKI; therefore, this document updates the RPKI Resource CertificatesProfile (RFC 6487). |
|
| |
| RFC 8210 | The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 |
| |
|
|
In order to verifiably validate the origin Autonomous Systems andAutonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure(RFC 6480) prefix origin data and router keys from a trusted cache.This document describes a protocol to deliver them.
This document describes version 1 of the RPKI-Router protocol. RFC6810 describes version 0. This document updates RFC 6810. |
|
| |
| RFC 8211 | Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Kent, D. Ma. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8211 |
|
This document analyzes actions by or against a CertificationAuthority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by RelyingParties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. |
|
| |
| RFC 8212 | Default External BGP (EBGP) Route Propagation Behavior without Policies |
| |
| Authors: | J. Mauch, J. Snijders, G. Hankins. |
| Date: | July 2017 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8212 |
|
This document updates RFC 4271 by defining the default behavior of aBGP speaker when there is no Import or Export Policy associated with an External BGP session. |
|
| |
| RFC 8213 | Security of Messages Exchanged between Servers and Relay Agents |
| |
| Authors: | B. Volz, Y. Pal. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8213 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6(DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4. |
|
| |
| RFC 8214 | Virtual Private Wire Service Support in Ethernet VPN |
| |
| Authors: | S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8214 |
|
This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks.EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. |
|
| |
| RFC 8215 | Local-Use IPv4/IPv6 Translation Prefix |
| |
| Authors: | T. Anderson. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8215 |
|
This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. |
|
| |
| RFC 8216 | HTTP Live Streaming |
| |
| Authors: | R. Pantos, Ed., W. May. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8216 |
|
This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients(receivers) of the streams. It describes version 7 of this protocol. |
|
| |
| RFC 8217 | Clarifications for When to Use the name-addr Production in SIP Messages |
| |
|
|
RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.
This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325,3515, 3892, 4508, 5002, 5318, 5360, and 5502). |
|
| |
| RFC 8218 | Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
| Authors: | J. Yi, B. Parrein. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8218 |
|
This document specifies a multipath extension for the Optimized LinkState Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained. |
|
| |
| RFC 8219 | Benchmarking Methodology for IPv6 Transition Technologies |
| |
| Authors: | M. Georgescu, L. Pislaru, G. Lencse. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8219 |
|
Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but theIPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability. |
|
| |
| RFC 8220 | Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) |
| |
| Authors: | O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8220 |
|
This document describes the procedures and recommendations forVirtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.
With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIMJoin/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstreamJoin/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.
This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices. |
|
| |
| RFC 8221 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
| Authors: | P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. |
| Date: | October 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 7321 |
| Updated by: | RFC 9395 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8221 |
|
This document replaces RFC 7321, "Cryptographic AlgorithmImplementation Requirements and Usage Guidance for EncapsulatingSecurity Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. |
|
| |
| RFC 8222 | Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery |
| |
| Authors: | A. Sullivan. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8222 |
|
Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to InternationalizedDomain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. |
|
| |
| RFC 8223 | Application-Aware Targeted LDP |
| |
| Authors: | S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza. |
| Date: | August 2017 |
| Formats: | txt json html |
| Updates: | RFC 7473 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8223 |
|
Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with anyLabel Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the TargetedApplication Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications.In addition, each targeted application is mapped to LDP ForwardingEquivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session. |
|
| |
| RFC 8224 | Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, C. Jennings, E. Rescorla, C. Wendt. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 4474 |
| Updated by: | RFC 8946 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8224 |
|
The baseline security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining aSIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
This document obsoletes RFC 4474. |
|
| |
| RFC 8225 | PASSporT: Personal Assertion Token |
| |
| Authors: | C. Wendt, J. Peterson. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8225 |
|
This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. |
|
| |
| RFC 8226 | Secure Telephone Identity Credentials: Certificates |
| |
| Authors: | J. Peterson, S. Turner. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8226 |
|
In order to prevent the impersonation of telephone numbers on theInternet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. |
|
| |
| RFC 8227 | MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology |
| |
| Authors: | W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8227 |
|
This document describes requirements, architecture, and solutions forMPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring. |
|
| |
| RFC 8228 | Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels |
| |
| Authors: | A. Freytag. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8228 |
|
Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets(LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants.The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940. |
|
| |
| RFC 8229 | TCP Encapsulation of IKE and IPsec Packets |
| |
| Authors: | T. Pauly, S. Touati, R. Mantha. |
| Date: | August 2017 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9329 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8229 |
|
This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. |
|
| |
| RFC 8230 | Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages |
| |
| Authors: | M. Jones. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8230 |
|
The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary ObjectRepresentation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used forCOSE messages. Encodings are specified for the use of RSAProbabilistic Signature Scheme (RSASSA-PSS) signatures, RSAEncryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys. |
|
| |
| RFC 8231 | Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and acrossPCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. |
|
| |
| RFC 8232 | Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE |
| |
| Authors: | E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8232 |
|
A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol(IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires aState Synchronization mechanism between the PCE and the network, thePCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. |
|
| |
| RFC 8233 | Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) |
| |
| Authors: | D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8233 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element CommunicationProtocol (PCEP) provides mechanisms for Path Computation Elements(PCEs) to perform path computations in response to Path ComputationClient (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. |
|
| |
| RFC 8234 | Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode |
| |
| Authors: | J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen. |
| Date: | August 2017 |
| Formats: | txt html json |
| Updates: | RFC 7271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8234 |
|
This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) ControlLogic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup. |
|
| |
| RFC 8235 | Schnorr Non-interactive Zero-Knowledge Proof |
| |
| Authors: | F. Hao, Ed.. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8235 |
|
This document describes the Schnorr non-interactive zero-knowledge(NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the SchnorrNIZK proof in both the finite field and the elliptic curve settings. |
|
| |
| RFC 8236 | J-PAKE: Password-Authenticated Key Exchange by Juggling |
| |
| Authors: | F. Hao, Ed.. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8236 |
|
This document specifies a Password-Authenticated Key Exchange byJuggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party. |
|
| |
| RFC 8237 | MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs |
| |
| Authors: | L. Martini, G. Swallow, E. Bellagamba. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8237 |
|
This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) LabelSwitched Path (LSP) to indicate the status of one or more PWs carried on the LSP.
The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. |
|
| |
| RFC 8238 | Data Center Benchmarking Terminology |
| |
| Authors: | L. Avramov, J. Rapp. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8238 |
|
The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. |
|
| |
| RFC 8239 | Data Center Benchmarking Methodology |
| |
| Authors: | L. Avramov, J. Rapp. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8239 |
|
The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. |
|
| |
| RFC 8240 | Report from the Internet of Things Software Update (IoTSU) Workshop 2016 |
| |
| Authors: | H. Tschofenig, S. Farrell. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8240 |
|
This document provides a summary of the Internet of Things SoftwareUpdate (IoTSU) Workshop that took place at Trinity College Dublin,Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices.This report summarizes the discussions and lists recommendations to the standards community.
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 8241 | Interface to the Routing System (I2RS) Security-Related Requirements |
| |
| Authors: | S. Hares, D. Migault, J. Halpern. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8241 |
|
This document presents security-related requirements for theInterface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them.One such reuse is of the security features of a secure transport(e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol,Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using theI2RS client, and an extremely constrained read-only non-secure transport. |
|
| |
| RFC 8242 | Interface to the Routing System (I2RS) Ephemeral State Requirements |
| |
| Authors: | J. Haas, S. Hares. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8242 |
|
"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System(I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. |
|
| |
| RFC 8243 | Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8243 |
|
Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?
This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases. |
|
| |
| RFC 8244 | Special-Use Domain Names Problem Statement |
| |
| Authors: | T. Lemon, R. Droms, W. Kumari. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8244 |
|
The policy defined in RFC 6761 for IANA registrations in the"Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic ofSpecial-Use Domain Names. |
|
| |
| RFC 8245 | Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 |
| |
| Authors: | T. Clausen, C. Dearlove, U. Herberg, H. Rogge. |
| Date: | October 2017 |
| Formats: | txt json html |
| Updates: | RFC 5444 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8245 |
|
RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexedMANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers. |
|
| |
| RFC 8246 | HTTP Immutable Responses |
| |
| Authors: | P. McManus. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8246 |
|
The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified. |
|
| |
| RFC 8247 | Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE) protocol is used to negotiate the IPsec SecurityAssociation (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updatesRFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsecEncapsulating Security Payload (ESP). |
|
| |
| RFC 8248 | Security Automation and Continuous Monitoring (SACM) Requirements |
| |
| Authors: | N. Cam-Winget, L. Lorenzin. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8248 |
|
This document defines the scope and set of requirements for theSecurity Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632. |
|
| |
| RFC 8249 | Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation |
| |
|
|
The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325,7177, and 7780. |
|
| |
| RFC 8250 | IPv6 Performance and Diagnostic Metrics (PDM) Destination Option |
| |
| Authors: | N. Elkins, R. Hamilton, M. Ackermann. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8250 |
|
To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) DestinationOptions header. The field limits, calculations, and usage in measurement of PDM are included in this document. |
|
| |
| RFC 8251 | Updates to the Opus Audio Codec |
| |
|
|
This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716.The changes fix real and potential security-related issues, as well as minor quality-related issues. |
|
| |
| RFC 8252 | OAuth 2.0 for Native Apps |
| |
|
|
OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. |
|
| |
| RFC 8253 | PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody. |
| Date: | October 2017 |
| Formats: | txt html json |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8253 |
|
The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path ComputationClient (PCC) and a Path Computation Element (PCE), or among PCEs.This document describes PCEPS -- the usage of Transport LayerSecurity (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.
This document updates RFC 5440 in regards to the PCEP initialization phase procedures. |
|
| |
| RFC 8254 | Uniform Resource Name (URN) Namespace Registration Transition |
| |
|
|
The original registration procedure for formal Uniform Resource Name(URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant olderRFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates. |
|
| |
| RFC 8255 | Multiple Language Content Type |
| |
| Authors: | N. Tomkinson, N. Borenstein. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8255 |
|
This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions(MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. |
|
| |
| RFC 8256 | Requirements for Hitless MPLS Path Segment Monitoring |
| |
| Authors: | A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8256 |
|
One of the most important Operations, Administration, and Maintenance(OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints.However, the current segment monitoring approach defined for MPLS(including the MPLS Transport Profile (MPLS-TP)) in RFC 6371"Operations, Administration, and Maintenance Framework for MPLS-BasedTransport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of newOAM tools to support Hitless Path Segment Monitoring (HPSM). |
|
| |
| RFC 8257 | Data Center TCP (DCTCP): TCP Congestion Control for Data Centers |
| |
| Authors: | S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8257 |
|
This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends theExplicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales theTCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. |
|
| |
| RFC 8258 | Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) |
| |
| Authors: | D. Ceccarelli, L. Berger. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8258 |
|
This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor(ISCD) Switching Capability Specific Information (SCSI) fields. This"Generalized SCSI" can be used with routing protocols that defineGMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards. |
|
| |
| RFC 8259 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 8260 | Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol |
| |
| Authors: | R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8260 |
|
The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.
Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving. |
|
| |
| RFC 8261 | Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets |
| |
|
|
The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocolsIPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, theSCTP associations carried over DTLS can only be single-homed. |
|
| |
| RFC 8262 | Content-ID Header Field in the Session Initiation Protocol (SIP) |
| |
|
|
This document specifies the Content-ID header field for usage in theSession Initiation Protocol (SIP). This document also updates RFC5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables aContent-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.
This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field. |
|
| |
| RFC 8263 | Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message |
| |
| Authors: | B. Weis, U. Mangla, T. Karl, N. Maheshwari. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8263 |
|
The Group Domain of Interpretation (GDOI) includes the ability of aGroup Controller/Key Server (GCKS) to provide a set of current GroupMember (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method. |
|
| |
| RFC 8264 | PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols |
| |
| Authors: | P. Saint-Andre, M. Blanchet. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 7564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8264 |
|
Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 7564. |
|
| |
| RFC 8265 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords |
| |
| Authors: | P. Saint-Andre, A. Melnikov. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 7613 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8265 |
|
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613. |
|
| |
| RFC 8266 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames |
| |
|
|
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. |
|
| |
| RFC 8267 | Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 |
| |
|
|
This document specifies Upper-Layer Bindings of Network File System(NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667. |
|
| |
| RFC 8268 | More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) |
| |
|
|
This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key. |
|
| |
| RFC 8269 | The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | W. Kim, J. Lee, J. Park, D. Kwon, D. Kim. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8269 |
|
This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA. |
|
| |
| RFC 8270 | Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits |
| |
| Authors: | L. Velvindron, M. Baushke. |
| Date: | December 2017 |
| Formats: | txt json html |
| Updates: | RFC 4419 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8270 |
|
The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits.Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updatesRFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size. |
|
| |
| RFC 8271 | Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) |
| |
| Authors: | M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia. |
| Date: | October 2017 |
| Formats: | txt json html |
| Updates: | RFC 4090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8271 |
|
This document updates the Resource Reservation Protocol - TrafficEngineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC4090 to support Packet Switch Capable (PSC) Generalized MultiprotocolLabel Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane. |
|
| |
| RFC 8272 | TinyIPFIX for Smart Meters in Constrained Networks |
| |
| Authors: | C. Schmitt, B. Stiller, B. Trammell. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8272 |
|
This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944).TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device. |
|
| |
| RFC 8273 | Unique IPv6 Prefix per Host |
| |
| Authors: | J. Brzozowski, G. Van de Velde. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8273 |
|
This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. |
|
| |
| RFC 8274 | Incident Object Description Exchange Format Usage Guidance |
| |
| Authors: | P. Kampanakis, M. Suzuki. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8274 |
|
The Incident Object Description Exchange Format (IODEF) v2 (RFC 7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged byComputer Security Incident Response Teams (CSIRTs). Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and provides use cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and to encourage faster and wider adoption of the model by CSIRTs around the world. |
|
| |
| RFC 8275 | Allowing Inheritable NFSv4 Access Control Entries to Override the Umask |
| |
| Authors: | J. Fields, A. Gruenbacher. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8275 |
|
In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that. |
|
| |
| RFC 8276 | File System Extended Attributes in NFSv4 |
| |
| Authors: | M. Naik, M. Eshel. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8276 |
|
This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects. |
|
| |
| RFC 8277 | Using BGP to Bind MPLS Labels to Address Prefixes |
| |
|
|
This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label(or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer ReachabilityInformation field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. |
|
| |
| RFC 8278 | Mobile Access Gateway (MAG) Multipath Options |
| |
| Authors: | P. Seite, A. Yegin, S. Gundavelli. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8278 |
|
This specification defines extensions to the Proxy Mobile IPv6(PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic.This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option. |
|
| |
| RFC 8279 | Multicast Using Bit Index Explicit Replication (BIER) |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8279 |
|
This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.This architecture is known as "Bit Index Explicit Replication"(BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in aBIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree- building protocols results in a considerable simplification. |
|
| |
| RFC 8280 | Research into Human Rights Protocol Considerations |
| |
|
|
This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.
This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights ProtocolConsiderations (HRPC) Research Group and also by individuals from outside the research group. |
|
| |
| RFC 8281 | Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model |
| |
| Authors: | E. Crabbe, I. Minei, S. Sivabalan, R. Varga. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8281 |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
The extensions for stateful PCE provide active control ofMultiprotocol Label Switching (MPLS) Traffic Engineering LabelSwitched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to thePCE. This document describes the creation and deletion ofPCE-initiated LSPs under the stateful PCE model. |
|
| |
| RFC 8282 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering |
| |
| Authors: | E. Oki, T. Takeda, A. Farrel, F. Zhang. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8282 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. |
|
| |
| RFC 8283 | An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control |
| |
| Authors: | A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8283 |
|
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths(LSPs), which are supplied to the head end of the LSP using the PathComputation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS traffic-engineered(TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service FunctionChaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability forPCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. |
|
| |
| RFC 8284 | Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages |
| |
| Authors: | S. Kille. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8284 |
|
The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory AccessProtocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications. |
|
| |
| RFC 8285 | A General Mechanism for RTP Header Extensions |
| |
| Authors: | D. Singer, H. Desineni, R. Even, Ed.. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 5285 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8285 |
|
This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285. |
|
| |
| RFC 8286 | RTP/RTCP Extension for RTP Splicing Notification |
| |
| Authors: | J. Xia, R. Even, R. Huang, L. Deng. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8286 |
|
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing- related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band. |
|
| |
| RFC 8287 | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes |
| |
| Authors: | N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. |
| Date: | December 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8690, RFC 9214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8287 |
|
A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of aMultiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.
The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture.This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix andIGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane. |
|
| |
| RFC 8288 | Web Linking |
| |
|
|
This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships("link relation types").
It also defines the serialisation of such links in HTTP headers with the Link header field. |
|
| |
| RFC 8289 | Controlled Delay Active Queue Management |
| |
| Authors: | K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed.. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8289 |
|
This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. |
|
| |
| RFC 8290 | The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm |
| |
| Authors: | T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8290 |
|
This memo presents the FQ-CoDel hybrid packet scheduler and ActiveQueue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.
FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. |
|
| |
| RFC 8291 | Message Encryption for Web Push |
| |
| Authors: | M. Thomson. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8291 |
|
This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent. |
|
| |
| RFC 8292 | Voluntary Application Server Identification (VAPID) for Web Push |
| |
| Authors: | M. Thomson, P. Beverloo. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8292 |
|
An application server can use the Voluntary Application ServerIdentification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server. |
|
| |
| RFC 8293 | A Framework for Multicast in Network Virtualization over Layer 3 |
| |
| Authors: | A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8293 |
|
This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3).Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms. |
|
| |
| RFC 8294 | Common YANG Data Types for the Routing Area |
| |
| Authors: | X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8294 |
|
This document defines a collection of common data types using theYANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. |
|
| |
| RFC 8295 | EST (Enrollment over Secure Transport) Extensions |
| |
| Authors: | S. Turner. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8295 |
|
The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI(Public Key Infrastructure) services, namely certificate enrollment(e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys.This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScriptObject Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. |
|
| |
| RFC 8296 | Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8296 |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network. |
|
| |
| RFC 8297 | An HTTP Status Code for Indicating Hints |
| |
| Authors: | K. Oku. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8297 |
|
This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. |
|
| |
| RFC 8298 | Self-Clocked Rate Adaptation for Multimedia |
| |
| Authors: | I. Johansson, Z. Sarker. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8298 |
|
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. |
|
| |
| RFC 8299 | YANG Data Model for L3VPN Service Delivery |
| |
| Authors: | Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki. |
| Date: | January 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 8049 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8299 |
|
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to theYANG module and some clarifications to the text. |
|
