| |
| RFC 7900 | Extranet Multicast in BGP/IP MPLS VPNs |
| |
|
|
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN(Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. |
|
| |
| RFC 7901 | CHAIN Query Requests in DNS |
| |
| Authors: | P. Wouters. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7901 |
|
This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks. |
|
| |
| RFC 7902 | Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags |
| |
|
|
The BGP-based control procedures for Multicast Virtual PrivateNetworks (MVPNs) make use of a BGP attribute known as the"P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community,"Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI)Tunnel" attribute. This document updates RFC 6514. |
|
| |
| RFC 7903 | Windows Image Media Types |
| |
| Authors: | S. Leonard. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7903 |
|
This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile,Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics. |
|
| |
| RFC 7904 | A SIP Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed.. |
| Date: | October 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7904 |
|
This document defines a SIP Usage for REsource LOcation And Discovery(RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also definesGlobally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. |
|
| |
| RFC 7905 | ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson. |
| Date: | June 2016 |
| Formats: | txt json html |
| Updates: | RFC 5246, RFC 6347 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7905 |
|
This document describes the use of the ChaCha stream cipher andPoly1305 authenticator in the Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS) protocols.
This document updates RFCs 5246 and 6347. |
|
| |
| RFC 7906 | NSA's Cryptographic Message Syntax (CMS) Key Management Attributes |
| |
| Authors: | P. Timmel, R. Housley, S. Turner. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7906 |
|
This document defines key management attributes used by the NationalSecurity Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic MessageSyntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used. |
|
| |
| RFC 7908 | Problem Definition and Classification of BGP Route Leaks |
| |
| Authors: | K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7908 |
|
A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention.Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community. |
|
| |
| RFC 7909 | Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures |
| |
|
|
This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on RoutingPolicy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects. |
|
| |
| RFC 7910 | Interoperability between the Virtual Router Redundancy Protocol and PIM |
| |
| Authors: | W. Zhou. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7910 |
|
This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with theVirtual Router Redundancy Protocol (VRRP). It allows PIM to trackVRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation. |
|
| |
| RFC 7911 | Advertisement of Multiple Paths in BGP |
| |
| Authors: | D. Walton, A. Retana, E. Chen, J. Scudder. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7911 |
|
This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix. |
|
| |
| RFC 7912 | Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure |
| |
| Authors: | A. Melnikov. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7912 |
|
This document describes a procedure for when a Military MessageHandling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more AuthorizingUsers authorize release of the message by adding theMMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures. |
|
| |
| RFC 7913 | P-Access-Network-Info ABNF Update |
| |
|
|
This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus-Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list. |
|
| |
| RFC 7914 | The scrypt Password-Based Key Derivation Function |
| |
| Authors: | C. Percival, S. Josefsson. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7914 |
|
This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. |
|
| |
| RFC 7915 | IP/ICMP Translation Algorithm |
| |
| Authors: | C. Bao, X. Li, F. Baker, T. Anderson, F. Gont. |
| Date: | June 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7915 |
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 6145. |
|
| |
| RFC 7916 | Operational Management of Loop-Free Alternates |
| |
| Authors: | S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7916 |
|
Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IPFast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.
This proposal is also applicable to remote-LFA solutions. |
|
| |
| RFC 7917 | Advertising Node Administrative Tags in IS-IS |
| |
| Authors: | P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7917 |
|
This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS. |
|
| |
| RFC 7918 | Transport Layer Security (TLS) False Start |
| |
| Authors: | A. Langley, N. Modadugu, B. Moeller. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7918 |
|
This document specifies an optional behavior of Transport LayerSecurity (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. |
|
| |
| RFC 7919 | Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) |
| |
|
|
Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings.These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.
This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography(ECC) extensions (RFC 4492). |
|
| |
| RFC 7920 | Problem Statement for the Interface to the Routing System |
| |
| Authors: | A. Atlas, Ed., T. Nadeau, Ed., D. Ward. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7920 |
|
Traditionally, routing systems have implemented routing and signaling(e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies.Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.
This document proposes meeting this need via an Interface to theRouting System (I2RS). |
|
| |
| RFC 7921 | An Architecture for the Interface to the Routing System |
| |
| Authors: | A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7921 |
|
This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS). |
|
| |
| RFC 7922 | Interface to the Routing System (I2RS) Traceability: Framework and Information Model |
| |
| Authors: | J. Clarke, G. Salgueiro, C. Pignataro. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7922 |
|
This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when.It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. |
|
| |
| RFC 7923 | Requirements for Subscription to YANG Datastores |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7923 |
|
This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., NetworkConfiguration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates.Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. |
|
| |
| RFC 7924 | Transport Layer Security (TLS) Cached Information Extension |
| |
| Authors: | S. Santesson, H. Tschofenig. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7924 |
|
Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).
This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information. |
|
| |
| RFC 7925 | Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things |
| |
| Authors: | H. Tschofenig, Ed., T. Fossati. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7925 |
|
A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.
This document defines a Transport Layer Security (TLS) and DatagramTransport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. |
|
| |
| RFC 7926 | Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks |
| |
| Authors: | A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang. |
| Date: | July 2016 |
| Formats: | txt html json |
| Also: | BCP 0206 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7926 |
|
In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity.This subset of TE information is called TE reachability information.
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. |
|
| |
| RFC 7927 | Information-Centric Networking (ICN) Research Challenges |
| |
| Authors: | D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7927 |
|
This memo describes research challenges for Information-CentricNetworking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching.Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 7928 | Characterization Guidelines for Active Queue Management (AQM) |
| |
| Authors: | N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7928 |
|
Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing.This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment. |
|
| |
| RFC 7929 | DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP |
| |
| Authors: | P. Wouters. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7929 |
|
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies aDANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the"web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. |
|
| |
| RFC 7930 | Larger Packets for RADIUS over TCP |
| |
|
|
The RADIUS-over-TLS experiment described in RFC 6614 has openedRADIUS to new use cases where the 4096-octet maximum size limit of aRADIUS packet proves problematic. This specification extends theRADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval. |
|
| |
| RFC 7931 | NFSv4.0 Migration: Specification Update |
| |
| Authors: | D. Noveck, Ed., P. Shivam, C. Lever, B. Baker. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 7530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7931 |
|
The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0.This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC7530. |
|
| |
| RFC 7932 | Brotli Compressed Data Format |
| |
| Authors: | J. Alakuijala, Z. Szabadka. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7932 |
|
This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. |
|
| |
| RFC 7933 | Adaptive Video Streaming over Information-Centric Networking (ICN) |
| |
| Authors: | C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7933 |
|
This document considers the consequences of moving the underlying network architecture from the current Internet to an Information-Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms.Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture ExpertsGroup (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms. |
|
| |
| RFC 7934 | Host Address Availability Recommendations |
| |
| Authors: | L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. |
| Date: | July 2016 |
| Formats: | txt json html |
| Also: | BCP 0204 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7934 |
|
This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so. |
|
| |
| RFC 7935 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 7936 | Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry |
| |
|
|
This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455. |
|
| |
| RFC 7937 | Content Distribution Network Interconnection (CDNI) Logging Interface |
| |
| Authors: | F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7937 |
|
This memo specifies the Logging interface between a downstreamContent Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework.First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. |
|
| |
| RFC 7938 | Use of BGP for Routing in Large-Scale Data Centers |
| |
| Authors: | P. Lapukhov, A. Premji, J. Mitchell, Ed.. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7938 |
|
Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry. |
|
| |
| RFC 7939 | Definition of Managed Objects for the Neighborhood Discovery Protocol |
| |
| Authors: | U. Herberg, R. Cole, I. Chakeres, T. Clausen. |
| Date: | August 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 6779 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7939 |
|
This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. |
|
| |
| RFC 7940 | Representing Label Generation Rulesets Using XML |
| |
| Authors: | K. Davies, A. Freytag. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7940 |
|
This document describes a method of representing rules for validating identifier labels and alternate representations of those labels usingExtensible Markup Language (XML). These policies, known as "LabelGeneration Rulesets" (LGRs), are used for the implementation ofInternationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. |
|
| |
| RFC 7941 | RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items |
| |
|
|
Source Description (SDES) items are normally transported in the RTPControl Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. |
|
| |
| RFC 7942 | Improving Awareness of Running Code: The Implementation Status Section |
| |
|
|
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. |
|
| |
| RFC 7943 | A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | F. Gont, W. Liu. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7943 |
|
This document describes a method for selecting IPv6 InterfaceIdentifiers that can be employed by Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless AddressAutoconfiguration. |
|
| |
| RFC 7944 | Diameter Routing Message Priority |
| |
| Authors: | S. Donovan. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7944 |
|
When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information,Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions. |
|
| |
| RFC 7945 | Information-Centric Networking: Evaluation and Security Considerations |
| |
| Authors: | K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7945 |
|
This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics. |
|
| |
| RFC 7946 | The GeoJSON Format |
| |
| Authors: | H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7946 |
|
GeoJSON is a geospatial data interchange format based on JavaScriptObject Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents.GeoJSON uses a geographic coordinate reference system, World GeodeticSystem 1984, and units of decimal degrees. |
|
| |
| RFC 7947 | Internet Exchange BGP Route Server |
| |
| Authors: | E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7947 |
|
This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such asIXPs, to facilitate simplified interconnection among multipleInternet routers. |
|
| |
| RFC 7948 | Internet Exchange BGP Route Server Operations |
| |
| Authors: | N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7948 |
|
The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP(EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.
Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.
This document describes operational considerations for multilateral interconnections at IXPs. |
|
| |
| RFC 7949 | OSPFv3 over IPv4 for IPv6 Transition |
| |
| Authors: | I. Chen, A. Lindem, R. Atkinson. |
| Date: | August 2016 |
| Formats: | txt html json |
| Updates: | RFC 5838 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7949 |
|
This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 AddressFamily extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4. |
|
| |
| RFC 7950 | The YANG 1.1 Data Modeling Language |
| |
|
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 7951 | JSON Encoding of Data Modeled with YANG |
| |
| Authors: | L. Lhotka. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7951 |
|
This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG asJavaScript Object Notation (JSON) text. |
|
| |
| RFC 7952 | Defining and Using Metadata with YANG |
| |
|
|
This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifiesXML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. |
|
| |
| RFC 7953 | Calendar Availability |
| |
|
|
This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendarTransport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.
This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time. |
|
| |
| RFC 7954 | Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block |
| |
| Authors: | L. Iannone, D. Lewis, D. Meyer, V. Fuller. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 7954 |
|
This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space. |
|
| |
| RFC 7955 | Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block |
| |
| Authors: | L. Iannone, R. Jorgensen, D. Conrad, G. Huston. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 7955 |
|
This document proposes a framework for the management of the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations. |
|
| |
| RFC 7956 | Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway |
| |
| Authors: | W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7956 |
|
The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter- subnet traffic forwarding but has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic.
2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per DataLabel used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.
3. A traffic bottleneck at the gateway.
This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues. |
|
| |
| RFC 7957 | DISPATCH-Style Working Groups and the SIP Change Process |
| |
|
|
RFC 5727 defined several processes for the former Real-timeApplications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. |
|
| |
| RFC 7958 | DNSSEC Trust Anchor Publication for the Root Zone |
| |
| Authors: | J. Abley, J. Schlyter, G. Bailey, P. Hoffman. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7958 |
|
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors. |
|
| |
| RFC 7959 | Block-Wise Transfers in the Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security(DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updatesRFC 7252. |
|
| |
| RFC 7960 | Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows |
| |
| Authors: | F. Martin, Ed., E. Lear, Ed., T. Draegen, Ed., E. Zwicky, Ed., K. Andersen, Ed.. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7960 |
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them. |
|
| |
| RFC 7961 | Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV |
| |
| Authors: | D. Eastlake 3rd, L. Yizhou. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7961 |
|
This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by aTRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 NeighborDiscovery (ND) protocol, or the flooding of unknown MAC addresses. |
|
| |
| RFC 7962 | Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures |
| |
| Authors: | J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7962 |
|
This document presents a taxonomy of a set of "Alternative NetworkDeployments" that emerged in the last decade with the aim of bringingInternet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives.They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.
The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.
The classification considers models such as Community Networks,Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives. |
|
| |
| RFC 7963 | RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) |
| |
| Authors: | Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7963 |
|
RFCs 4328 and 7139 provide signaling extensions in ResourceReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit(ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2).This document defines new Signal Types for these additional containers. |
|
| |
| RFC 7964 | Solutions for BGP Persistent Route Oscillation |
| |
| Authors: | D. Walton, A. Retana, E. Chen, J. Scudder. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7964 |
|
Routing information reduction by BGP Route Reflection orConfederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies.This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network. |
|
| |
| RFC 7965 | LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels |
| |
| Authors: | M. Chen, W. Cao, A. Takacs, P. Pan. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7965 |
|
Many transport services require that user traffic, in the form ofPseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to theLabel Distribution Protocol (LDP) that enables the binding betweenPWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs. |
|
| |
| RFC 7966 | Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements |
| |
| Authors: | H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7966 |
|
This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs). |
|
| |
| RFC 7967 | Constrained Application Protocol (CoAP) Option for No Server Response |
| |
| Authors: | A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7967 |
|
There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.
This specification introduces a CoAP option called 'No-Response'.Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request.This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of theNo-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. |
|
| |
| RFC 7968 | Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data |
| |
| Authors: | Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7968 |
|
TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN,FGL, or multicast group can be sent on any tree, for typical fast- path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.
This document specifies an optional facility to restrict the TRILLData packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware. |
|
| |
| RFC 7969 | Customizing DHCP Configuration on the Basis of Network Topology |
| |
| Authors: | T. Lemon, T. Mrugalski. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7969 |
|
DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications.One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation. |
|
| |
| RFC 7970 | The Incident Object Description Exchange Format Version 2 |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletesRFCs 5070 and 6685. |
|
| |
| RFC 7971 | Application-Layer Traffic Optimization (ALTO) Deployment Considerations |
| |
| Authors: | M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7971 |
|
Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing andContent Delivery Networks (CDNs) and presents corresponding examples.The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information. |
|
| |
| RFC 7972 | Entertainment Identifier Registry (EIDR) URN Namespace Definition |
| |
|
|
Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers.
This document obsoletes RFC 7302. |
|
| |
| RFC 7973 | Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation |
| |
| Authors: | R. Droms, P. Duffy. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7973 |
|
When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment. |
|
| |
| RFC 7974 | An Experimental TCP Option for Host Identification |
| |
| Authors: | B. Williams, M. Boucadair, D. Wing. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7974 |
|
Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed.This memo describes the design, deployment, and privacy considerations for one such solution in operational use on theInternet today that uses a TCP option to transmit a host identifier. |
|
| |
| RFC 7975 | Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection |
| |
| Authors: | B. Niven-Jenkins, Ed., R. van Brandenburg, Ed.. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7975 |
|
The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream ContentDelivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface. |
|
| |
| RFC 7976 | Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses |
| |
| Authors: | C. Holmberg, N. Biondic, G. Salgueiro. |
| Date: | September 2016 |
| Formats: | txt json html |
| Updates: | RFC 7315 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7976 |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315.This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
|
| |
| RFC 7977 | The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath. |
| Date: | September 2016 |
| Formats: | txt json html |
| Updates: | RFC 4975, RFC 4976 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7977 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol(MSRP) clients and relays to enable usage of MSRP in new scenarios.This document normatively updates RFCs 4975 and 4976. |
|
| |
| RFC 7978 | Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension |
| |
| Authors: | D. Eastlake 3rd, M. Umair, Y. Li. |
| Date: | September 2016 |
| Formats: | txt html json |
| Updates: | RFC 7178 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7978 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages betweenTRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link.This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178. |
|
| |
| RFC 7979 | Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries |
| |
| Authors: | E. Lear, Ed., R. Housley, Ed.. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7979 |
|
The U.S. National Telecommunications and Information Administration(NTIA) solicited a request from the Internet Corporation for AssignedNames and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANAStewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in theAppendix. |
|
| |
| RFC 7980 | A Framework for Defining Network Complexity |
| |
| Authors: | M. Behringer, A. Retana, R. White, G. Huston. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7980 |
|
Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.
This document summarizes the work of the IRTF's Network ComplexityResearch Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work. |
|
| |
| RFC 7981 | IS-IS Extensions for Advertising Router Information |
| |
| Authors: | L. Ginsberg, S. Previdi, M. Chen. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 4971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7981 |
|
This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletesRFC 4971. |
|
| |
| RFC 7982 | Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | P. Martinsen, T. Reddy, D. Wing, V. Singh. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7982 |
|
A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.
This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session TraversalUtilities for NAT (STUN) messages. |
|
| |
| RFC 7983 | Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) |
| |
|
|
This document defines how Datagram Transport Layer Security (DTLS),Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTPExtension for DTLS"), which suffered from four issues described and fixed in this document.
This document updates RFC 5764. |
|
| |
| RFC 7984 | Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network |
| |
| Authors: | O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed.. |
| Date: | September 2016 |
| Formats: | txt html json |
| Updates: | RFC 3263 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7984 |
|
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "HappyEyeballs" principles to SIP. |
|
| |
| RFC 7985 | Security Threats to Simplified Multicast Forwarding (SMF) |
| |
| Authors: | J. Yi, T. Clausen, U. Herberg. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 7186 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7985 |
|
This document analyzes security threats to Simplified MulticastForwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.
In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network(MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130). |
|
| |
| RFC 7986 | New Properties for iCalendar |
| |
|
|
This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object. |
|
| |
| RFC 7987 | IS-IS Minimum Remaining Lifetime |
| |
| Authors: | L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler. |
| Date: | October 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7987 |
|
Corruption of the Remaining Lifetime field in a Link State ProtocolData Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial- of-service attack vector. This document defines a backwards- compatible solution to this problem. |
|
| |
| RFC 7988 | Ingress Replication Tunnels in Multicast VPN |
| |
|
|
RFCs 6513, 6514, and other RFCs describe procedures by which aService Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an"Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. |
|
| |
| RFC 7989 | End-to-End Session Identification in IP-Based Multimedia Communication Networks |
| |
| Authors: | P. Jones, G. Salgueiro, C. Pearce, P. Giralt. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 7329 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7989 |
|
This document describes an end-to-end session identifier for use inIP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the SessionInitiation Protocol (SIP).
This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.
This document obsoletes RFC 7329. |
|
| |
| RFC 7990 | RFC Format Framework |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7990 |
|
In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan. |
|
| |
| RFC 7991 | The "xml2rfc" Version 3 Vocabulary |
| |
|
|
This document defines the "xml2rfc" version 3 vocabulary: anXML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described inRFC 7749. |
|
| |
| RFC 7992 | HTML Format for RFCs |
| |
| Authors: | J. Hildebrand, Ed., P. Hoffman. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7992 |
|
In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft. |
|
| |
| RFC 7993 | Cascading Style Sheets (CSS) Requirements for RFCs |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7993 |
|
The HTML format for RFCs assigns style guidance to a Cascading StyleSheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992). |
|
| |
| RFC 7994 | Requirements for Plain-Text RFCs |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7994 |
|
In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format forRFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. |
|
| |
| RFC 7995 | PDF Format for RFCs |
| |
| Authors: | T. Hansen, Ed., L. Masinter, M. Hardy. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7995 |
|
This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF. |
|
| |
| RFC 7996 | SVG Drawings for RFCs: SVG 1.2 RFC |
| |
| Authors: | N. Brownlee. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7996 |
|
This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams. |
|
| |
| RFC 7997 | The Use of Non-ASCII Characters in RFCs |
| |
|
|
In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
This document updates RFC 7322. Please view this document in PDF form to see the full text. |
|
| |
| RFC 7998 | "xml2rfc" Version 3 Preparation Tool Description |
| |
| Authors: | P. Hoffman, J. Hildebrand. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7998 |
|
This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed. |
|
| |
| RFC 7999 | BLACKHOLE Community |
| |
| Authors: | T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7999 |
|
This document describes the use of a well-known Border GatewayProtocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named"BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix. |
|
