| |
| RFC 8000 | Requirements for NFSv4 Multi-Domain Namespace Deployment |
| |
| Authors: | A. Adamson, N. Williams. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8000 |
|
This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain- capable file system and support RPCSEC_GSS for user authentication.In most instances, the server must also support identity-mapping services. |
|
| |
| RFC 8001 | RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information |
| |
| Authors: | F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8001 |
|
This document provides extensions for Resource Reservation Protocol -Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). |
|
| |
| RFC 8002 | Host Identity Protocol Certificates |
| |
|
|
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).
The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 7401 and obsoletes RFC 6253. |
|
| |
| RFC 8003 | Host Identity Protocol (HIP) Registration Extension |
| |
| Authors: | J. Laganier, L. Eggert. |
| Date: | October 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 5203 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8003 |
|
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203. |
|
| |
| RFC 8004 | Host Identity Protocol (HIP) Rendezvous Extension |
| |
| Authors: | J. Laganier, L. Eggert. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 5204 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8004 |
|
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIPRegistration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204. |
|
| |
| RFC 8005 | Host Identity Protocol (HIP) Domain Name System (DNS) Extension |
| |
|
|
This document specifies a resource record (RR) for the Domain NameSystem (DNS) and how to use it with the Host Identity Protocol (HIP).This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its HostIdentity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205. |
|
| |
| RFC 8006 | Content Delivery Network Interconnection (CDNI) Metadata |
| |
| Authors: | B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8006 |
|
The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNIMetadata and the protocol for exchanging that metadata. |
|
| |
| RFC 8007 | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers |
| |
| Authors: | R. Murray, B. Niven-Jenkins. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8007 |
|
This document describes the part of the Content Delivery NetworkInterconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. |
|
| |
| RFC 8008 | Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics |
| |
| Authors: | J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. |
| Date: | December 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9388 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8008 |
|
This document captures the semantics of the "Footprint andCapabilities Advertisement" part of the Content Delivery NetworkInterconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for theCDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. |
|
| |
| RFC 8009 | AES Encryption with HMAC-SHA2 for Kerberos 5 |
| |
| Authors: | M. Jenkins, M. Peck, K. Burgin. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8009 |
|
This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode(CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. |
|
| |
| RFC 8010 | Internet Printing Protocol/1.1: Encoding and Transport |
| |
|
|
The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called"application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/orHTTPS. The IPP data model and operation semantics are described in"Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).
This document obsoletes RFCs 2910 and 3382. |
|
| |
| RFC 8011 | Internet Printing Protocol/1.1: Model and Semantics |
| |
|
|
The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.
IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of PrintJobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.
Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).
This document obsoletes RFCs 2911, 3381, and 3382. |
|
| |
| RFC 8012 | Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) |
| |
| Authors: | N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin. |
| Date: | November 2016 |
| Formats: | txt json html |
| Updates: | RFC 6790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8012 |
|
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where LabelSwitching Routers (LSRs) apply different load-balancing techniques.One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g.,IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.
This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790. |
|
| |
| RFC 8013 | Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) |
| |
| Authors: | D. Joachimpillai, J. Hadi Salim. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8013 |
|
This document describes how to extend the Forwarding and ControlElement Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class.The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification.The document focuses on Ethernet transport. |
|
| |
| RFC 8014 | An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) |
| |
| Authors: | D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8014 |
|
This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components. |
|
| |
| RFC 8015 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics |
| |
| Authors: | V. Singh, C. Perkins, A. Clark, R. Huang. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8015 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications. |
|
| |
| RFC 8016 | Mobility with Traversal Using Relays around NAT (TURN) |
| |
| Authors: | T. Reddy, D. Wing, P. Patil, P. Martinsen. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8016 |
|
It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.
This document provides such an IP address mobility solution usingTraversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when theIP address of the client changes. |
|
| |
| RFC 8017 | PKCS #1: RSA Cryptography Specifications Version 2.2 |
| |
| Authors: | K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch. |
| Date: | November 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 3447 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8017 |
|
This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
This document represents a republication of PKCS #1 v2.2 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447. |
|
| |
| RFC 8018 | PKCS #5: Password-Based Cryptography Specification Version 2.1 |
| |
| Authors: | K. Moriarty, Ed., B. Kaliski, A. Rusch. |
| Date: | January 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 2898 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8018 |
|
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.
This document represents a republication of PKCS #5 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 2898. |
|
| |
| RFC 8019 | Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks |
| |
| Authors: | Y. Nir, V. Smyslov. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8019 |
|
This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2)Responders, to allow them to resist Denial-of-Service and DistributedDenial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task. |
|
| |
| RFC 8020 | NXDOMAIN: There Really Is Nothing Underneath |
| |
|
|
This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. |
|
| |
| RFC 8021 | Generation of IPv6 Atomic Fragments Considered Harmful |
| |
| Authors: | F. Gont, W. Liu, T. Anderson. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8021 |
|
This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460). |
|
| |
| RFC 8022 | A YANG Data Model for Routing Management |
| |
| Authors: | L. Lhotka, A. Lindem. |
| Date: | November 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8349 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8022 |
|
This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes,Routing Information Bases (RIBs), and control-plane protocols. |
|
| |
| RFC 8023 | Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions |
| |
| Authors: | M. Thomas, A. Mankin, L. Zhang. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8023 |
|
This document provides context and a report on the workshop on "RootCauses and Mitigation of Name Collisions", which took place inLondon, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions. |
|
| |
| RFC 8024 | Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS |
| |
| Authors: | Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8024 |
|
Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) OpticalLine Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on theMPLS-enabled PON OLT to provide resiliency for provided services.This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-ChassisCommunication Protocol (ICCP) extension to support it. |
|
| |
| RFC 8025 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch |
| |
| Authors: | P. Thubert, Ed., R. Cragie. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 4944 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8025 |
|
This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network(6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch. |
|
| |
| RFC 8026 | Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism |
| |
| Authors: | M. Boucadair, I. Farrer. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8026 |
|
In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of CustomerPremises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism. |
|
| |
| RFC 8027 | DNSSEC Roadblock Avoidance |
| |
| Authors: | W. Hardaker, O. Gudmundsson, S. Krishnaswamy. |
| Date: | November 2016 |
| Formats: | txt json html |
| Also: | BCP 0207 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8027 |
|
This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. |
|
| |
| RFC 8028 | First-Hop Router Selection by Hosts in a Multi-Prefix Network |
| |
| Authors: | F. Baker, B. Carpenter. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8028 |
|
This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen.Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their RouterAdvertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC4861. |
|
| |
| RFC 8029 | Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures |
| |
| Authors: | K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. |
| Date: | March 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 4379, RFC 6424, RFC 6829, RFC 7537 |
| Updates: | RFC 1122 |
| Updated by: | RFC 8611, RFC 9041 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8029 |
|
This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) LabelSwitched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.
This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updatesRFC 1122. |
|
| |
| RFC 8030 | Generic Event Delivery Using HTTP Push |
| |
| Authors: | M. Thomson, E. Damaggio, B. Raymor, Ed.. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8030 |
|
This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push. |
|
| |
| RFC 8031 | Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement |
| |
| Authors: | Y. Nir, S. Josefsson. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8031 |
|
This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version2 (IKEv2). |
|
| |
| RFC 8032 | Edwards-Curve Digital Signature Algorithm (EdDSA) |
| |
| Authors: | S. Josefsson, I. Liusvaara. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8032 |
|
This document describes elliptic curve signature scheme Edwards-curveDigital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. |
|
| |
| RFC 8033 | Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem |
| |
| Authors: | R. Pan, P. Natarajan, F. Baker, G. White. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8033 |
|
Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.
This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value.Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software. |
|
| |
| RFC 8034 | Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems |
| |
| Authors: | G. White, R. Pan. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8034 |
|
Cable modems based on Data-Over-Cable Service InterfaceSpecifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management(AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the"DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems. |
|
| |
| RFC 8035 | Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing |
| |
|
|
This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute. |
|
| |
| RFC 8036 | Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks |
| |
| Authors: | N. Cam-Winget, Ed., J. Hui, D. Popa. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8036 |
|
This document discusses the applicability of the Routing Protocol forLow-Power and Lossy Networks (RPL) in Advanced MeteringInfrastructure (AMI) networks. |
|
| |
| RFC 8037 | CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | I. Liusvaara. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8037 |
|
This document defines how to use the Diffie-Hellman algorithms"X25519" and "X448" as well as the signature algorithms "Ed25519" and"Ed448" from the IRTF CFRG elliptic curves work in JSON ObjectSigning and Encryption (JOSE). |
|
| |
| RFC 8038 | Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol |
| |
| Authors: | P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8038 |
|
This document specifies a way to complement IP Flow InformationExport (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.
Two IPFIX Options Templates, as well as a method for creating IPFIXOptions Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein. |
|
| |
| RFC 8039 | Multipath Time Synchronization |
| |
| Authors: | A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8039 |
|
Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality. |
|
| |
| RFC 8040 | RESTCONF Protocol |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | January 2017 |
| Formats: | txt json html |
| Updated by: | RFC 8527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8040 |
|
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 8041 | Use Cases and Operational Experience with Multipath TCP |
| |
| Authors: | O. Bonaventure, C. Paasch, G. Detal. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8041 |
|
This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements. |
|
| |
| RFC 8042 | OSPF Two-Part Metric |
| |
| Authors: | Z. Zhang, L. Wang, A. Lindem. |
| Date: | December 2016 |
| Formats: | txt html json |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8042 |
|
This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric forOSPF route computation is the sum of the two parts. This document updates RFC 2328. |
|
| |
| RFC 8043 | Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space |
| |
| Authors: | B. Sarikaya, M. Boucadair. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8043 |
|
This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.
The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations. |
|
| |
| RFC 8044 | Data Types in RADIUS |
| |
|
|
RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include aData Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072,6158, 6572, and 7268. |
|
| |
| RFC 8045 | RADIUS Extensions for IP Port Configuration and Reporting |
| |
| Authors: | D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8045 |
|
This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-GradeNAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP FlowInformation Export (IPFIX) Information Element identifiers. |
|
| |
| RFC 8046 | Host Mobility with the Host Identity Protocol |
| |
| Authors: | T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | February 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 5206 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8046 |
|
This document defines a mobility extension to the Host IdentityProtocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts.The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC5206. |
|
| |
| RFC 8047 | Host Multihoming with the Host Identity Protocol |
| |
| Authors: | T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8047 |
|
This document defines host multihoming extensions to the HostIdentity Protocol (HIP), by leveraging protocol components defined for host mobility. |
|
| |
| RFC 8048 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence |
| |
|
|
This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). This document obsoletes RFC 7248. |
|
| |
| RFC 8049 | YANG Data Model for L3VPN Service Delivery |
| |
| Authors: | S. Litkowski, L. Tomotaki, K. Ogaki. |
| Date: | February 2017 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8299 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8049 |
|
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. |
|
| |
| RFC 8050 | Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions |
| |
| Authors: | C. Petrie, T. King. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8050 |
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions. |
|
| |
| RFC 8051 | Applicability of a Stateful Path Computation Element (PCE) |
| |
| Authors: | X. Zhang, Ed., I. Minei, Ed.. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8051 |
|
A stateful Path Computation Element (PCE) maintains information aboutLabel Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE CommunicationProtocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. |
|
| |
| RFC 8052 | Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services |
| |
| Authors: | B. Weis, M. Seewald, H. Falk. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8052 |
|
The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC62351-9 standards specify the use of the Group Domain ofInterpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo definesGDOI payloads to support those security protocols. |
|
| |
| RFC 8053 | HTTP Authentication Extensions for Interactive Clients |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8053 |
|
This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps betweenWeb application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication. |
|
| |
| RFC 8054 | Network News Transfer Protocol (NNTP) Extension for Compression |
| |
| Authors: | K. Murchison, J. Elie. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8054 |
|
This document defines an extension to the Network News TransportProtocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server. |
|
| |
| RFC 8055 | Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm |
| |
| Authors: | C. Holmberg, Y. Jiang. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8055 |
|
This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network. |
|
| |
| RFC 8056 | Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping |
| |
| Authors: | J. Gould. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8056 |
|
This document describes the mapping of the Extensible ProvisioningProtocol (EPP) statuses with the statuses registered for use in theRegistration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP. |
|
| |
| RFC 8057 | Uniform Resource Name (URN) Namespaces for Broadband Forum |
| |
| Authors: | B. Stark, D. Sinicrope, W. Lupton. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8057 |
|
This document describes the Namespace Identifiers (NIDs) "bbf","broadband-forum-org", and "dslforum-org" for Uniform Resource Names(URNs) used to identify resources published by Broadband Forum (BBF).BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF. |
|
| |
| RFC 8058 | Signaling One-Click Functionality for List Email Headers |
| |
| Authors: | J. Levine, T. Herkula. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8058 |
|
This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field. |
|
| |
| RFC 8059 | PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments |
| |
| Authors: | J. Arango, S. Venaas, I. Kouvelas, D. Farinacci. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8059 |
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol(LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey theRLOC (Routing Locator) address of the receiver ETR (Egress TunnelRouter) to the control plane of the root ITR (Ingress Tunnel Router). |
|
| |
| RFC 8060 | LISP Canonical Address Format (LCAF) |
| |
| Authors: | D. Farinacci, D. Meyer, J. Snijders. |
| Date: | February 2017 |
| Formats: | txt json html |
| Updated by: | RFC 9306 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8060 |
|
This document defines a canonical address format encoding used inLocator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. |
|
| |
| RFC 8061 | Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality |
| |
| Authors: | D. Farinacci, B. Weis. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8061 |
|
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks. |
|
| |
| RFC 8062 | Anonymity Support for Kerberos |
| |
|
|
This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletesRFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. |
|
| |
| RFC 8063 | Key Relay Mapping for the Extensible Provisioning Protocol |
| |
| Authors: | H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8063 |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.
This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. |
|
| |
| RFC 8064 | Recommendation on Stable IPv6 Interface Identifiers |
| |
| Authors: | F. Gont, A. Cooper, D. Thaler, W. Liu. |
| Date: | February 2017 |
| Formats: | txt json html |
| Updates: | RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, RFC 5121 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8064 |
|
This document changes the recommended default Interface Identifier(IID) generation scheme for cases where Stateless AddressAutoconfiguration (SLAAC) is used to generate a stable IPv6 address.It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. |
|
| |
| RFC 8065 | Privacy Considerations for IPv6 Adaptation-Layer Mechanisms |
| |
| Authors: | D. Thaler. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8065 |
|
This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links. |
|
| |
| RFC 8066 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines |
| |
| Authors: | S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. |
| Date: | February 2017 |
| Formats: | txt html json |
| Updates: | RFC 4944, RFC 6282 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8066 |
|
RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document. |
|
| |
| RFC 8067 | Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level |
| |
|
|
RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents. |
|
| |
| RFC 8068 | Session Initiation Protocol (SIP) Recording Call Flows |
| |
| Authors: | R. Ravindranath, P. Ravindran, P. Kyzivat. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8068 |
|
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons.The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording Server (SRS). |
|
| |
| RFC 8069 | URN Namespace for IEEE |
| |
| Authors: | A. Thomas. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8069 |
|
This document describes the Namespace Identifier (NID) 'ieee' forUniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority. |
|
| |
| RFC 8070 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension |
| |
| Authors: | M. Short, Ed., S. Moore, P. Miller. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8070 |
|
This document describes how to further extend the Public KeyCryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINITAuthentication Service (AS) exchange. |
|
| |
| RFC 8071 | NETCONF Call Home and RESTCONF Call Home |
| |
| Authors: | K. Watsen. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8071 |
|
This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively. |
|
| |
| RFC 8072 | YANG Patch Media Type |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8072 |
|
This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. |
|
| |
| RFC 8073 | Coordinating Attack Response at Internet Scale (CARIS) Workshop Report |
| |
| Authors: | K. Moriarty, M. Ford. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8073 |
|
This report documents the discussions and conclusions from theCoordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.
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 8074 | Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario |
| |
| Authors: | J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8074 |
|
In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods. |
|
| |
| RFC 8075 | Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8075 |
|
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. |
|
| |
| RFC 8076 | A Usage for Shared Resources in RELOAD (ShaRe) |
| |
| Authors: | A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8076 |
|
This document defines a REsource LOcation And Discovery (RELOAD)Usage for managing shared write access to RELOAD Resources. SharedResources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A newUSER-CHAIN-ACL access policy allows authorized peers to write aShared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required. |
|
| |
| RFC 8077 | Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) |
| |
|
|
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol(LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.
This document is a rewrite of RFC 4447 for publication as an InternetStandard. |
|
| |
| RFC 8078 | Managing DS Records from the Parent via CDS/CDNSKEY |
| |
| Authors: | O. Gudmundsson, P. Wouters. |
| Date: | March 2017 |
| Formats: | txt json html |
| Updates: | RFC 7344 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8078 |
|
RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevatesRFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. |
|
| |
| RFC 8079 | Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | L. Miniero, S. Garcia Murillo, V. Pascual. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8079 |
|
SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol(RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP. |
|
| |
| RFC 8080 | Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC |
| |
| Authors: | O. Sury, R. Edmonds. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8080 |
|
This document describes how to specify Edwards-curve Digital SecurityAlgorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448. |
|
| |
| RFC 8081 | The "font" Top-Level Media Type |
| |
| Authors: | C. Lilley. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8081 |
|
This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations. |
|
| |
| RFC 8082 | Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs |
| |
| Authors: | S. Wenger, J. Lennox, B. Burman, M. Westerlund. |
| Date: | March 2017 |
| Formats: | txt html json |
| Updates: | RFC 5104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8082 |
|
This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full IntraRequest (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found. |
|
| |
| RFC 8083 | Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions |
| |
|
|
The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactiveRTP flows.
This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by theseRTP circuit breaker algorithms. |
|
| |
| RFC 8084 | Network Transport Circuit Breakers |
| |
|
|
This document explains what is meant by the term "network transportCircuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet. |
|
| |
| RFC 8085 | UDP Usage Guidelines |
| |
|
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ExplicitCongestion Notification (ECN), Differentiated Services Code Points(DSCPs), and ports.
Because congestion control is critical to the stable operation of theInternet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.
Some guidance is also applicable to the design of other protocols(e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.
This document obsoletes RFC 5405 and adds guidelines for multicastUDP usage. |
|
| |
| RFC 8086 | GRE-in-UDP Encapsulation |
| |
| Authors: | L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8086 |
|
This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field.This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms.There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet. |
|
| |
| RFC 8087 | The Benefits of Using Explicit Congestion Notification (ECN) |
| |
| Authors: | G. Fairhurst, M. Welzl. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8087 |
|
The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit CongestionNotification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits whenECN is used over a network path that includes equipment that supportsCongestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices. |
|
| |
| RFC 8088 | How to Write an RTP Payload Format |
| |
|
|
This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. |
|
| |
| RFC 8089 | The "file" URI Scheme |
| |
|
|
This document provides a more complete specification of the "file"Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.
It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs. |
|
| |
| RFC 8090 | Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) |
| |
| Authors: | R. Housley. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8090 |
|
This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names. |
|
| |
| RFC 8091 | A Media Type Structured Syntax Suffix for JSON Text Sequences |
| |
| Authors: | E. Wilde. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8091 |
|
Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences. |
|
| |
| RFC 8092 | BGP Large Communities Attribute |
| |
| Authors: | J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8092 |
|
This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all AutonomousSystem Numbers (ASNs) including four-octet ASNs. |
|
| |
| RFC 8093 | Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 |
| |
| Authors: | J. Snijders. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8093 |
|
This document requests IANA to mark BGP path attribute values 30, 31,129, 241, 242, and 243 as "Deprecated". |
|
| |
| RFC 8094 | DNS over Datagram Transport Layer Security (DTLS) |
| |
| Authors: | T. Reddy, D. Wing, P. Patil. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8094 |
|
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.
This document proposes the use of Datagram Transport Layer Security(DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. |
|
| |
| RFC 8095 | Services Provided by IETF Transport Protocols and Congestion Control Mechanisms |
| |
| Authors: | G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8095 |
|
This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines theTransmission Control Protocol (TCP), Multipath TCP, the StreamControl Transmission Protocol (SCTP), the User Datagram Protocol(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), theInternet Control Message Protocol (ICMP), the Real-Time TransportProtocol (RTP), File Delivery over Unidirectional Transport /Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS),Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. |
|
| |
| RFC 8096 | The IPv6-Specific MIB Modules Are Obsolete |
| |
|
|
In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoletedIPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic. |
|
| |
| RFC 8097 | BGP Prefix Origin Validation State Extended Community |
| |
| Authors: | P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8097 |
|
This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process. |
|
| |
| RFC 8098 | Message Disposition Notification |
| |
|
|
This memo defines a MIME content type that may be used by a Mail UserAgent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content type is intended to be machine processable. Additional message header fields are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and are often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.
This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461(Original-Recipient header field generation requirement). |
|
| |
| RFC 8099 | OSPF Topology-Transparent Zone |
| |
| Authors: | H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8099 |
|
This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ. |
|
