| |
| RFC 8100 | Diffserv-Interconnection Classes and Practice |
| |
| Authors: | R. Geib, Ed., D. Black. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8100 |
|
This document defines a limited common set of Diffserv Per-HopBehaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at(inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operateMultiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation ofDiffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS. |
|
| |
| RFC 8101 | IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service |
| |
| Authors: | C. Holmberg, J. Axell. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8101 |
|
This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry. |
|
| |
| RFC 8102 | Remote-LFA Node Protection and Manageability |
| |
| Authors: | P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8102 |
|
The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.
This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints. |
|
| |
| RFC 8103 | Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8103 |
|
This document describes the conventions for using ChaCha20-Poly1305Authenticated Encryption in the Cryptographic Message Syntax (CMS).ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. |
|
| |
| RFC 8104 | Pseudowire (PW) Endpoint Fast Failure Protection |
| |
| Authors: | Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8104 |
|
This document specifies a fast mechanism for protecting pseudowires(PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. |
|
| |
| RFC 8105 | Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) |
| |
| Authors: | P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8105 |
|
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy(ULE) is a low-power air interface technology that is proposed by theDECT Forum and is defined and specified by ETSI.
The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.
DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE usingIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
|
| |
| RFC 8106 | IPv6 Router Advertisement Options for DNS Configuration |
| |
| Authors: | J. Jeong, S. Park, L. Beloeil, S. Madanapalli. |
| Date: | March 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 6106 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8106 |
|
This document specifies IPv6 Router Advertisement (RA) options(called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.
This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. |
|
| |
| RFC 8107 | Advertising Digital Identifier (Ad-ID) URN Namespace Definition |
| |
| Authors: | J. Wold. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8107 |
|
Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID)"adid" for Ad-IDs. |
|
| |
| RFC 8108 | Sending Multiple RTP Streams in a Single RTP Session |
| |
|
|
This memo expands and clarifies the behavior of Real-time TransportProtocol (RTP) endpoints that use multiple synchronization sources(SSRCs). This occurs, for example, when an endpoint sends multipleRTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages. |
|
| |
| RFC 8109 | Initializing a DNS Resolver with Priming Queries |
| |
| Authors: | P. Koch, M. Larson, P. Hoffman. |
| Date: | March 2017 |
| Formats: | txt json html |
| Also: | BCP 0209 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8109 |
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. |
|
| |
| RFC 8110 | Opportunistic Wireless Encryption |
| |
| Authors: | D. Harkins, Ed., W. Kumari, Ed.. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8110 |
|
This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. |
|
| |
| RFC 8111 | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
| Authors: | V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8111 |
|
This document describes the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISPEndpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set ofLISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. |
|
| |
| RFC 8112 | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) |
| |
| Authors: | D. Farinacci, A. Jain, I. Kouvelas, D. Lewis. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8112 |
|
A simple tool called the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP-DDT hierarchy. This document describes how the "rig" tool works. |
|
| |
| RFC 8113 | Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations |
| |
|
|
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830. |
|
| |
| RFC 8114 | Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network |
| |
| Authors: | M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8114 |
|
This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced byDual-Stack Lite (DS-Lite). |
|
| |
| RFC 8115 | DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes |
| |
| Authors: | M. Boucadair, J. Qin, T. Tsou, X. Deng. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8115 |
|
This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses. |
|
| |
| RFC 8116 | Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
| Authors: | T. Clausen, U. Herberg, J. Yi. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8116 |
|
This document analyzes common security threats to the Optimized LinkState Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated. |
|
| |
| RFC 8117 | Current Hostname Practice Considered Harmful |
| |
| Authors: | C. Huitema, D. Thaler, R. Winter. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8117 |
|
Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.
There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values. |
|
| |
| RFC 8118 | The application/pdf Media Type |
| |
| Authors: | M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey. |
| Date: | March 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 3778 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8118 |
|
The Portable Document Format (PDF) is an ISO standard (ISO32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778. |
|
| |
| RFC 8119 | SIP "cause" URI Parameter for Service Number Translation |
| |
|
|
RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the UserAgent Server (UAS) receiving the message. This document updates RFC4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations. |
|
| |
| RFC 8120 | Mutual Authentication Protocol for HTTP |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8120 |
|
This document specifies an authentication scheme for the HypertextTransfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. |
|
| |
| RFC 8121 | Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8121 |
|
This document specifies cryptographic algorithms for use with theMutual user authentication method for the Hypertext Transfer Protocol(HTTP). |
|
| |
| RFC 8122 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. |
|
| |
| RFC 8123 | Requirements for Marking SIP Messages to be Logged |
| |
| Authors: | P. Dawes, C. Arunachalam. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8123 |
|
SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.
This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks. |
|
| |
| RFC 8124 | The Session Description Protocol (SDP) WebSocket Connection URI Attribute |
| |
| Authors: | R. Ravindranath, G. Salgueiro. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8124 |
|
The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport. |
|
| |
| RFC 8125 | Requirements for Password-Authenticated Key Agreement (PAKE) Schemes |
| |
| Authors: | J. Schmidt. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8125 |
|
Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password.This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group(CFRG). |
|
| |
| RFC 8126 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226. |
|
| |
| RFC 8127 | Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor |
| |
| Authors: | D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8127 |
|
This specification defines a new extension,LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters. |
|
| |
| RFC 8128 | IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee |
| |
| Authors: | C. Morgan. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8128 |
|
This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC). |
|
| |
| RFC 8129 | Authentication Indicator in Kerberos Tickets |
| |
| Authors: | A. Jain, N. Kinder, N. McCallum. |
| Date: | March 2017 |
| Formats: | txt json html |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8129 |
|
This document updates RFC 4120, as it specifies an extension in theKerberos protocol. It defines a new authorization data type,AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. |
|
| |
| RFC 8130 | RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec |
| |
| Authors: | V. Demjanenko, D. Satterlee. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8130 |
|
This document describes the RTP payload format for the MixedExcitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail. |
|
| |
| RFC 8131 | RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing |
| |
| Authors: | X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8131 |
|
In non-packet transport networks, there are requirements where theGeneralized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.
This document reviews how the LSP association is to be provided usingResource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature. |
|
| |
| RFC 8132 | PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) |
| |
| Authors: | P. van der Stok, C. Bormann, A. Sehgal. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8132 |
|
The methods defined in RFC 7252 for the Constrained ApplicationProtocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.
This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. |
|
| |
| RFC 8133 | The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8133 |
|
This document describes the Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects. |
|
| |
| RFC 8134 | Management Incident Lightweight Exchange (MILE) Implementation Report |
| |
| Authors: | C. Inacio, D. Miyamoto. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8134 |
|
This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) andManagement Incident Lightweight Exchange (MILE) working groups. |
|
| |
| RFC 8135 | Complex Addressing in IPv6 |
| |
| Authors: | M. Danielson, M. Nilsson. |
| Date: | 1 April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8135 |
|
The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges. |
|
| |
| RFC 8136 | Additional Transition Functionality for IPv6 |
| |
| Authors: | B. Carpenter, R. Hinden. |
| Date: | 1 April 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8136 |
|
This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy. |
|
| |
| RFC 8137 | IEEE 802.15.4 Information Element for the IETF |
| |
| Authors: | T. Kivinen, P. Kinney. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8137 |
|
IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15Assigned Numbers Authority (ANA) manages the registry of theInformation Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes. |
|
| |
| RFC 8138 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header |
| |
|
|
This specification introduces a new IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of RoutingProtocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. |
|
| |
| RFC 8139 | Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders |
| |
|
|
TRILL (Transparent Interconnection of Lots of Links) supports multi- access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multipleTRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates theAppointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439. |
|
| |
| RFC 8140 | The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8140 |
|
Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.
Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International TradeMark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".
This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author. |
|
| |
| RFC 8141 | Uniform Resource Names (URNs) |
| |
|
|
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with theInternet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. |
|
| |
| RFC 8142 | GeoJSON Text Sequences |
| |
| Authors: | S. Gillies. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8142 |
|
This document describes the GeoJSON text sequence format and"application/geo+json-seq" media type. This format is based onJavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence. |
|
| |
| RFC 8143 | Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |
| |
|
|
This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport LayerSecurity (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642. |
|
| |
| RFC 8144 | Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.
This document updates RFC 7240. |
|
| |
| RFC 8145 | Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) |
| |
| Authors: | D. Wessels, W. Kumari, P. Hoffman. |
| Date: | April 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8145 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in aDNSSEC-signed zone. |
|
| |
| RFC 8146 | Adding Support for Salted Password Databases to EAP-pwd |
| |
|
|
EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft ChallengeHandshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd. |
|
| |
| RFC 8147 | Next-Generation Pan-European eCall |
| |
| Authors: | R. Gellens, H. Tschofenig. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8147 |
|
This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.
This document also registers MIME media types and an Emergency CallData Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.
Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions. |
|
| |
| RFC 8148 | Next-Generation Vehicle-Initiated Emergency Calls |
| |
| Authors: | R. Gellens, B. Rosen, H. Tschofenig. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8148 |
|
This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident.Such calls are often referred to as "Automatic Crash Notification"(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.
This document also registers a MIME media type and Emergency CallData Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.
This document reuses the technical aspects of next-generation Pan-European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions).However, this document specifies use of a different set of vehicle(crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy(circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. |
|
| |
| RFC 8149 | RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) |
| |
| Authors: | T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8149 |
|
The reoptimization of a Point-to-Multipoint (P2MP) TrafficEngineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break(MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point- to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list. |
|
| |
| RFC 8150 | MPLS Transport Profile Linear Protection MIB |
| |
| Authors: | S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8150 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - TransportProfile (MPLS-TP) linear protection. |
|
| |
| RFC 8151 | Use Cases for Data Center Network Virtualization Overlay Networks |
| |
| Authors: | L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8151 |
|
This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications. |
|
| |
| RFC 8152 | CBOR Object Signing and Encryption (COSE) |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format.This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. |
|
| |
| RFC 8153 | Digital Preservation Considerations for the RFC Series |
| |
| Authors: | H. Flanagan. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8153 |
|
The RFC Editor is both the publisher and the archivist for the RFCSeries. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserveRFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice. |
|
| |
| RFC 8154 | Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout |
| |
| Authors: | C. Hellwig. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8154 |
|
The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices. |
|
| |
| RFC 8155 | Traversal Using Relays around NAT (TURN) Server Auto Discovery |
| |
| Authors: | P. Patil, T. Reddy, D. Wing. |
| Date: | April 2017 |
| Formats: | txt html json |
| Updates: | RFC 5766 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8155 |
|
Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise,ISP, or the network in which the client is located. Enterprises andISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms forTURN server discovery.
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases. |
|
| |
| RFC 8156 | DHCPv6 Failover Protocol |
| |
| Authors: | T. Mrugalski, K. Kinnear. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8156 |
|
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6(DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031). |
|
| |
| RFC 8157 | Huawei's GRE Tunnel Bonding Protocol |
| |
| Authors: | N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8157 |
|
There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single ServiceProvider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE TunnelBonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber.Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations. |
|
| |
| RFC 8158 | IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events |
| |
| Authors: | S. Sivakumar, R. Penno. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8158 |
|
Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that theNAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events. |
|
| |
| RFC 8159 | Keyed IPv6 Tunnel |
| |
| Authors: | M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8159 |
|
This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane. |
|
| |
| RFC 8160 | IUTF8 Terminal Mode in Secure Shell (SSH) |
| |
| Authors: | S. Tatham, D. Tucker. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8160 |
|
This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding. |
|
| |
| RFC 8161 | Benchmarking the Neighbor Discovery Protocol |
| |
| Authors: | W. Cerveny, R. Bonica, R. Thomas. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8161 |
|
This document provides benchmarking procedures for the NeighborDiscovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured. |
|
| |
| RFC 8162 | Using Secure DNS to Associate Certificates with Domain Names for S/MIME |
| |
| Authors: | P. Hoffman, J. Schlyter. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8162 |
|
This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. |
|
| |
| RFC 8163 | Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks |
| |
| Authors: | K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8163 |
|
Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. |
|
| |
| RFC 8164 | Opportunistic Security for HTTP/2 |
| |
| Authors: | M. Nottingham, M. Thomson. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 8164 |
|
This document describes how "http" URIs can be accessed usingTransport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https"URIs; it is vulnerable to active attacks. |
|
| |
| RFC 8165 | Design Considerations for Metadata Insertion |
| |
| Authors: | T. Hardie. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8165 |
|
The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata. |
|
| |
| RFC 8166 | Remote Direct Memory Access Transport for Remote Procedure Call Version 1 |
| |
|
|
This document specifies a protocol for conveying Remote ProcedureCall (RPC) messages on physical transports capable of Remote DirectMemory Access (RDMA). This protocol is referred to as the RPC-over-RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666. |
|
| |
| RFC 8167 | Bidirectional Remote Procedure Call on RPC-over-RDMA Transports |
| |
| Authors: | C. Lever. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8167 |
|
Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection.This document describes how RPC transport endpoints capable of RemoteDirect Memory Access (RDMA) convey RPCs in both directions on a single connection. |
|
| |
| RFC 8168 | DHCPv6 Prefix-Length Hint Issues |
| |
| Authors: | T. Li, C. Liu, Y. Cui. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8168 |
|
DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix- length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. |
|
| |
| RFC 8169 | Residence Time Measurement in MPLS Networks |
| |
| Authors: | G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8169 |
|
This document specifies a new Generic Associated Channel (G-ACh) forResidence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.
Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a PrecisionTime Protocol event message. |
|
| |
| RFC 8170 | Planning for Protocol Adoption and Subsequent Transitions |
| |
| Authors: | D. Thaler, Ed.. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8170 |
|
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan. |
|
| |
| RFC 8171 | Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms |
| |
| Authors: | D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8171 |
|
This document describes mechanisms for providing directory service toTRILL (Transparent Interconnection of Lots of Links) edge switches.The directory information provided can be used in reducing multi- destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. |
|
| |
| RFC 8172 | Considerations for Benchmarking Virtual Network Functions and Their Infrastructure |
| |
| Authors: | A. Morton. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8172 |
|
The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware. |
|
| |
| RFC 8173 | Precision Time Protocol Version 2 (PTPv2) Management Information Base |
| |
| Authors: | V. Shankarkumar, L. Montini, T. Frost, G. Dowd. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8173 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.
This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions. |
|
| |
| RFC 8174 | Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words |
| |
|
|
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. |
|
| |
| RFC 8175 | Dynamic Link Exchange Protocol (DLEP) |
| |
| Authors: | S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8175 |
|
When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol(DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics. |
|
| |
| RFC 8176 | Authentication Method Reference Values |
| |
| Authors: | M. Jones, P. Hunt, A. Nadalin. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8176 |
|
The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry forAuthentication Method Reference values and defines an initial set ofAuthentication Method Reference values. |
|
| |
| RFC 8177 | YANG Data Model for Key Chains |
| |
| Authors: | A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8177 |
|
This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. |
|
| |
| RFC 8178 | Rules for NFSv4 Extensions and Minor Versions |
| |
|
|
This document describes the rules relating to the extension of theNFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as ProposedStandards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions. |
|
| |
| RFC 8179 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.This document also obsoletes RFCs 3979 and 4879. |
|
| |
| RFC 8180 | Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration |
| |
| Authors: | X. Vilajosana, Ed., K. Pister, T. Watteyne. |
| Date: | May 2017 |
| Formats: | txt html json |
| Also: | BCP 0210 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8180 |
|
This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH providesIPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices. |
|
| |
| RFC 8181 | A Publication Protocol for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Weiler, A. Sonalker, R. Austein. |
| Date: | July 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8181 |
|
This document defines a protocol for publishing Resource Public KeyInfrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects.Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs. |
|
| |
| RFC 8182 | The RPKI Repository Delta Protocol (RRDP) |
| |
|
|
In the Resource Public Key Infrastructure (RPKI), CertificateAuthorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a newRPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an UpdateNotification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security(TLS)), and it enables the use of Content Distribution Networks(CDNs) or other caching infrastructures for the retrieval of these files. |
|
| |
| RFC 8183 | An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services |
| |
| Authors: | R. Austein. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8183 |
|
This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.
This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. |
|
| |
| RFC 8184 | Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires |
| |
| Authors: | W. Cheng, L. Wang, H. Li, S. Davari, J. Dong. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8184 |
|
This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. ThisPW dual-homing local protection mechanism is complementary to existing PW protection mechanisms. |
|
| |
| RFC 8185 | Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection |
| |
| Authors: | W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8185 |
|
In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs)(RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the PacketSwitched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection. |
|
| |
| RFC 8186 | Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | G. Mirsky, I. Meilik. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8186 |
|
This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to theNetwork Time Protocol that is currently used. |
|
| |
| RFC 8187 | Indicating Character Encoding and Language for HTTP Header Field Parameters |
| |
|
|
By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.
This document obsoletes RFC 5987. |
|
| |
| RFC 8188 | Encrypted Content-Encoding for HTTP |
| |
| Authors: | M. Thomson. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8188 |
|
This memo introduces a content coding for HTTP that allows message payloads to be encrypted. |
|
| |
| RFC 8189 | Multi-Cost Application-Layer Traffic Optimization (ALTO) |
| |
| Authors: | S. Randriamasy, W. Roome, N. Schwan. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8189 |
|
The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.
This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics. |
|
| |
| RFC 8190 | Updates to the Special-Purpose IP Address Registries |
| |
|
|
This memo updates the IANA IPv4 and IPv6 Special-Purpose AddressRegistries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890. |
|
| |
| RFC 8191 | Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) |
| |
| Authors: | Z. Yan, J. Lee, X. Lee. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8191 |
|
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node(MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with theHNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations whenHNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification. |
|
| |
| RFC 8192 | Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases |
| |
| Authors: | S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8192 |
|
This document sets out the problem statement for Interface to NetworkSecurity Functions (I2NSF) and outlines some companion use cases. |
|
| |
| RFC 8193 | Information Model for Large-Scale Measurement Platforms (LMAPs) |
| |
| Authors: | T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8193 |
|
This Information Model applies to the Measurement Agent within anLMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols. |
|
| |
| RFC 8194 | A YANG Data Model for LMAP Measurement Agents |
| |
| Authors: | J. Schoenwaelder, V. Bajpai. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8194 |
|
This document defines a data model for Large-Scale MeasurementPlatforms (LMAPs). The data model is defined using the YANG data modeling language. |
|
| |
| RFC 8195 | Use of BGP Large Communities |
| |
| Authors: | J. Snijders, J. Heasley, M. Schmidt. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8195 |
|
This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire. |
|
| |
| RFC 8196 | IS-IS Autoconfiguration |
| |
| Authors: | B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8196 |
|
This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected. |
|
| |
| RFC 8197 | A SIP Response Code for Unwanted Calls |
| |
| Authors: | H. Schulzrinne. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8197 |
|
This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted.SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. |
|
| |
| RFC 8198 | Aggressive Use of DNSSEC-Validated Cache |
| |
|
|
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certainDoS attacks in some circumstances.
This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. |
|
| |
| RFC 8199 | YANG Module Classification |
| |
| Authors: | D. Bogdanovic, B. Claise, C. Moberg. |
| Date: | July 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8199 |
|
The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.
A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.
This document describes a set of concepts and associated terms to support consistent classification of YANG modules. |
|
