| |
| RFC 8300 | Network Service Header (NSH) |
| |
| Authors: | P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. |
| Date: | January 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9451 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8300 |
|
This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining(SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). |
|
| |
| RFC 8301 | Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) |
| |
|
|
The cryptographic algorithm and key size requirements included whenDomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. |
|
| |
| RFC 8302 | Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization |
| |
| Authors: | Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8302 |
|
This document describes mechanisms to optimize the Address ResolutionProtocol (ARP) and Neighbor Discovery (ND) traffic in a TransparentInterconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / DataLabel bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edgeRouting Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus. |
|
| |
| RFC 8303 | On the Usage of Transport Features Provided by IETF Transport Protocols |
| |
| Authors: | M. Welzl, M. Tuexen, N. Khademi. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8303 |
|
This document describes how the transport protocols TransmissionControl Protocol (TCP), MultiPath TCP (MPTCP), Stream ControlTransmission Protocol (SCTP), User Datagram Protocol (UDP), andLightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services(TAPS) API. |
|
| |
| RFC 8304 | Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) |
| |
| Authors: | G. Fairhurst, T. Jones. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8304 |
|
This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols. |
|
| |
| RFC 8305 | Happy Eyeballs Version 2: Better Connectivity Using Concurrency |
| |
| Authors: | D. Schinazi, T. Pauly. |
| Date: | December 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 6555 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8305 |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. |
|
| |
| RFC 8306 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. |
| Date: | November 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 6006 |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8306 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE Communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
This document obsoletes RFC 6006. |
|
| |
| RFC 8307 | Well-Known URIs for the WebSocket Protocol |
| |
|
|
RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and"https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes. |
|
| |
| RFC 8308 | Extension Negotiation in the Secure Shell (SSH) Protocol |
| |
|
|
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially afterSSH key exchange. |
|
| |
| RFC 8309 | Service Models Explained |
| |
| Authors: | Q. Wu, W. Liu, A. Farrel. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8309 |
|
The IETF has produced many modules in the YANG modeling language.The majority of these modules are used to construct data models to model devices or monolithic functions.
A small number of YANG modules have been defined to model services(for example, the Layer 3 Virtual Private Network Service Model(L3SM) produced by the L3SM working group and documented in RFC8049).
This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. |
|
| |
| RFC 8310 | Usage Profiles for DNS over TLS and DNS over DTLS |
| |
| Authors: | S. Dickinson, D. Gillmor, T. Reddy. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7858 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8310 |
|
This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over TransportLayer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to aDNS server. Additionally, it defines (D)TLS protocol profiles forDNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. |
|
| |
| RFC 8311 | Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation |
| |
|
|
This memo updates RFC 3168, which specifies Explicit CongestionNotification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. AnExperimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341,4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. |
|
| |
| RFC 8312 | CUBIC for Fast Long-Distance Networks |
| |
| Authors: | I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9438 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8312 |
|
CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC. |
|
| |
| RFC 8313 | Use of Multicast across Inter-domain Peering Points |
| |
| Authors: | P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Also: | BCP 0213 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8313 |
|
This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process. |
|
| |
| RFC 8314 | Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |
| |
|
|
This specification outlines current recommendations for the use ofTransport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501,5068, 6186, and 6409. |
|
| |
| RFC 8315 | Cancel-Locks in Netnews Articles |
| |
|
|
This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles.This document updates RFC 5537. |
|
| |
| RFC 8316 | Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations |
| |
| Authors: | J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8316 |
|
This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements(SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It is published for informational purposes. |
|
| |
| RFC 8317 | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Updates: | RFC 7385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8317 |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol LabelSwitching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432,"BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796,"Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service(VPLS)". This document makes use of the most significant bit of theTunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly. |
|
| |
| RFC 8318 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 8319 | Support for Adjustable Maximum Router Lifetimes per Link |
| |
| Authors: | S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8319 |
|
The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements(RAs) from a router interface as well as the maximum router lifetime.It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.
This document specifies updates to the IPv6 Neighbor DiscoveryProtocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime. |
|
| |
| RFC 8320 | LDP Extensions to Support Maximally Redundant Trees |
| |
| Authors: | A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8320 |
|
This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of Label Switched Paths (LSPs) forMaximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as"MRT-FRR".
The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) andLabel Edge Routers (LERs) advertising the MRT Capability.
MRT-FRR uses LDP multi-topology extensions, so three multi-topologyIDs have been allocated from the MPLS MT-ID space. |
|
| |
| RFC 8321 | Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. |
| Date: | January 2018 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9341 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8321 |
|
This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on anAlternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application. |
|
| |
| RFC 8322 | Resource-Oriented Lightweight Information Exchange (ROLIE) |
| |
| Authors: | J. Field, S. Banghart, D. Waltermire. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8322 |
|
This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources.Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the AtomPublishing Protocol and Atom Syndication Format to transport and share security automation resource representations. |
|
| |
| RFC 8323 | CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets |
| |
| Authors: | C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. |
| Date: | February 2018 |
| Formats: | txt html json |
| Updates: | RFC 7641, RFC 7959 |
| Updated by: | RFC 8974 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8323 |
|
The Constrained Application Protocol (CoAP), although inspired byHTTP, was designed to use UDP instead of TCP. The message layer ofCoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS).This document outlines the changes required to use CoAP over TCP,TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. |
|
| |
| RFC 8324 | DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? |
| |
| Authors: | J. Klensin. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8324 |
|
The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way. |
|
| |
| RFC 8325 | Mapping Diffserv to IEEE 802.11 |
| |
| Authors: | T. Szigeti, J. Henry, F. Baker. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 8622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8325 |
|
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. |
|
| |
| RFC 8326 | Graceful BGP Session Shutdown |
| |
| Authors: | P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8326 |
|
This document standardizes a new well-known BGP community,GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance. |
|
| |
| RFC 8327 | Mitigating the Negative Impact of Maintenance through BGP Session Culling |
| |
| Authors: | W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. |
| Date: | March 2018 |
| Formats: | txt html json |
| Also: | BCP 0214 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8327 |
|
This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence. |
|
| |
| RFC 8328 | Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) |
| |
| Authors: | W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8328 |
|
The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy.These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces. |
|
| |
| RFC 8329 | Framework for Interface to Network Security Functions |
| |
| Authors: | D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8329 |
|
This document describes the framework for Interface to NetworkSecurity Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions(NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated. |
|
| |
| RFC 8330 | OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth |
| |
| Authors: | H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8330 |
|
A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word"availability" is typically used to describe such links during network planning. This document defines a new type of GeneralizedSwitching Capability-Specific Information (SCSI) TLV to extend theGeneralized Multiprotocol Label Switching (GMPLS) Open Shortest PathFirst (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses. |
|
| |
| RFC 8331 | RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data |
| |
| Authors: | T. Edwards. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8331 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers(SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1.SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). |
|
| |
| RFC 8332 | Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol |
| |
|
|
This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections. |
|
| |
| RFC 8333 | Micro-loop Prevention by Introducing a Local Convergence Delay |
| |
| Authors: | S. Litkowski, B. Decraene, C. Filsfils, P. Francois. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8333 |
|
This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.
Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.
The mechanism is limited to the link-down event in order to keep the mechanism simple.
Simulations using real network topologies have been performed and show that local loops are a significant portion (&rt;50%) of the total forwarding loops. |
|
| |
| RFC 8334 | Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | J. Gould, W. Tan, G. Brown. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8334 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. |
|
| |
| RFC 8335 | PROBE: A Utility for Probing Interfaces |
| |
| Authors: | R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updates: | RFC 4884 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8335 |
|
This document describes a network diagnostic tool called PROBE.PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. |
|
| |
| RFC 8336 | The ORIGIN HTTP/2 Frame |
| |
| Authors: | M. Nottingham, E. Nygren. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8336 |
|
This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. |
|
| |
| RFC 8337 | Model-Based Metrics for Bulk Transport Capacity |
| |
| Authors: | M. Mathis, A. Morton. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8337 |
|
This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.
Model-Based Metrics rely on mathematical models to specify a TargetedIP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.
For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the TargetTransport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications. |
|
| |
| RFC 8338 | Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP |
| |
| Authors: | S. Boutros, Ed., S. Sivabalan, Ed.. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8338 |
|
This document specifies a mechanism to signal Point-to-Multipoint(P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP orMPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type. |
|
| |
| RFC 8339 | Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms |
| |
| Authors: | P. Jain, Ed., S. Boutros, S. Aldrin. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8339 |
|
Label Switched Path (LSP) Ping is a widely deployed Operation,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes a mechanism to verify connectivity of Point- to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping. |
|
| |
| RFC 8340 | YANG Tree Diagrams |
| |
|
|
This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. |
|
| |
| RFC 8341 | Network Configuration Access Control Model |
| |
|
|
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.
This document obsoletes RFC 6536. |
|
| |
| RFC 8342 | Network Management Datastore Architecture (NMDA) |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8342 |
|
Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF.This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. |
|
| |
| RFC 8343 | A YANG Data Model for Interface Management |
| |
|
|
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.
This document obsoletes RFC 7223. |
|
| |
| RFC 8344 | A YANG Data Model for IP Management |
| |
|
|
This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342.
This document obsoletes RFC 7277. |
|
| |
| RFC 8345 | A YANG Data Model for Network Topologies |
| |
| Authors: | A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8345 |
|
This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. |
|
| |
| RFC 8346 | A YANG Data Model for Layer 3 Topologies |
| |
| Authors: | A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8346 |
|
This document defines a YANG data model for Layer 3 network topologies. |
|
| |
| RFC 8347 | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
| Authors: | X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8347 |
|
This document describes a data model for the Virtual RouterRedundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. |
|
| |
| RFC 8348 | A YANG Data Model for Hardware Management |
| |
| Authors: | A. Bierman, M. Bjorklund, J. Dong, D. Romascanu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8348 |
|
This document defines a YANG data model for the management of hardware on a single server. |
|
| |
| RFC 8349 | A YANG Data Model for Routing Management (NMDA Version) |
| |
| Authors: | L. Lhotka, A. Lindem, Y. Qu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 8022 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8349 |
|
This document specifies three YANG modules and one submodule.Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, RoutingInformation Bases (RIBs), and control-plane protocols.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA). This document obsoletes RFC 8022. |
|
| |
| RFC 8350 | Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8350 |
|
Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between theWireless Transmission Point (WTP) and Access Controller (AC).Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP DataChannel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an AccessRouter (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and theAccess Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring theWTP. |
|
| |
| RFC 8351 | The PKCS #8 EncryptedPrivateKeyInfo Media Type |
| |
| Authors: | S. Leonard. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8351 |
|
This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value. |
|
| |
| RFC 8352 | Energy-Efficient Features of Internet of Things Protocols |
| |
| Authors: | C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed.. |
| Date: | April 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8352 |
|
This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks. |
|
| |
| RFC 8353 | Generic Security Service API Version 2: Java Bindings Update |
| |
| Authors: | M. Upadhyay, S. Malkani, W. Wang. |
| Date: | May 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 5653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8353 |
|
The Generic Security Services Application Programming Interface(GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update"(RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined forGSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)"(RFC 2025) and "The Kerberos Version 5 Generic Security ServiceApplication Program Interface (GSS-API) Mechanism: Version 2"(RFC 4121). |
|
| |
| RFC 8354 | Use Cases for IPv6 Source Packet Routing in Networking (SPRING) |
| |
| Authors: | J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8354 |
|
The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through anIPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in anIPv6-only environment. |
|
| |
| RFC 8355 | Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8355 |
|
This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on SourcePacket Routing in Networking (SPRING) networks. |
|
| |
| RFC 8356 | Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Dhody, D. King, A. Farrel. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8356 |
|
IANA assigns values to the Path Computation Element CommunicationProtocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries forPCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.
This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use. |
|
| |
| RFC 8357 | Generalized UDP Source Port for DHCP Relay |
| |
| Authors: | N. Shen, E. Chen. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8357 |
|
This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications. |
|
| |
| RFC 8358 | Update to Digital Signatures on Internet-Draft Documents |
| |
|
|
RFC 5485 specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
This document updates RFC 5485. |
|
| |
| RFC 8359 | Network-Assigned Upstream Label |
| |
|
|
This document discusses a Generalized Multi-Protocol Label Switching(GMPLS) Resource reSerVation Protocol with Traffic Engineering(RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object. |
|
| |
| RFC 8360 | Resource Public Key Infrastructure (RPKI) Validation Reconsidered |
| |
| Authors: | G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8360 |
|
This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource PublicKey Infrastructure (RPKI), while retaining essential security features.
The procedure specified in RFC 6487 requires that ResourceCertificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing CertificationAuthority (CA) to chose to communicate that such ResourceCertificates should be accepted for the intersection of their resources and the issuing certificate.
It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.
This choice is signaled by a set of alternative Object Identifiers(OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers"(RFC 3779) and "Certificate Policy (CP) for the Resource Public KeyInfrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.
Furthermore, this document provides an alternative to Route OriginAuthorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsecPKI Profiles -- publication requested) validation. |
|
| |
| RFC 8361 | Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic |
| |
| Authors: | W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu. |
| Date: | April 2018 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8361 |
|
In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges(RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325).To avoid RPF check failure on an RBridge sitting between the ingressRBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325. |
|
| |
| RFC 8362 | OSPFv3 Link State Advertisement (LSA) Extensibility |
| |
| Authors: | A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker. |
| Date: | April 2018 |
| Formats: | txt json html |
| Updates: | RFC 5340, RFC 5838 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8362 |
|
OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described inRFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separateLSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information inType-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.
This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,"Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. |
|
| |
| RFC 8363 | GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8363 |
|
The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its RecommendationsG.694.1 and G.872 to include a new Dense Wavelength DivisionMultiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot".Corresponding techniques for data-plane connections are known as"flexi-grid".
Based on the characteristics of flexi-grid defined in G.694.1 and inRFCs 7698 and 7699, this document describes the Open Shortest PathFirst - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. |
|
| |
| RFC 8364 | PIM Flooding Mechanism (PFM) and Source Discovery (SD) |
| |
|
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses aRendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIMFlooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets. |
|
| |
| RFC 8365 | A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8365 |
|
This document specifies how Ethernet VPN (EVPN) can be used as aNetwork Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on theEVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN),Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to GenericNetwork Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifiesEVPN route constructions for VXLAN/NVGRE encapsulations andAutonomous System Border Router (ASBR) procedures for multihoming ofNetwork Virtualization Edge (NVE) devices. |
|
| |
| RFC 8366 | A Voucher Artifact for Bootstrapping Protocols |
| |
| Authors: | K. Watsen, M. Richardson, M. Pritikin, T. Eckert. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8366 |
|
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".
This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax(CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer(i.e., the Manufacturer Authorized Signing Authority (MASA)).
This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. |
|
| |
| RFC 8367 | Wrongful Termination of Internet Protocol (IP) Packets |
| |
| Authors: | T. Mizrahi, J. Yallouz. |
| Date: | 1 April 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8367 |
|
Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them. |
|
| |
| RFC 8368 | Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | T. Eckert, Ed., M. Behringer. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8368 |
|
Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.
This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies. |
|
| |
| RFC 8369 | Internationalizing IPv6 Using 128-Bit Unicode |
| |
| Authors: | H. Kaplan. |
| Date: | 1 April 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8369 |
|
It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the UnicodeConsortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6. |
|
| |
| RFC 8370 | Techniques to Improve the Scalability of RSVP-TE Deployments |
| |
| Authors: | V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8370 |
|
Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number ofLSPs deployed.
This document defines two techniques, Refresh-Interval IndependentRSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in LabelSwitching Routers (LSRs) and hence allow implementations to support larger scale deployments. |
|
| |
| RFC 8371 | Mobile Node Identifier Types for MIPv6 |
| |
| Authors: | C. Perkins, V. Devarapalli. |
| Date: | July 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8371 |
|
This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283. |
|
| |
| RFC 8372 | MPLS Flow Identification Considerations |
| |
| Authors: | S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8372 |
|
This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets. |
|
| |
| RFC 8373 | Negotiating Human Language in Real-Time Communications |
| |
|
|
Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages.This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).
This document describes the need as well as a solution that uses newSDP media attributes. |
|
| |
| RFC 8374 | BGPsec Design Choices and Summary of Supporting Discussions |
| |
| Authors: | K. Sriram, Ed.. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8374 |
|
This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification).The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETFSIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes. |
|
| |
| RFC 8375 | Special-Use Domain 'home.arpa.' |
| |
|
|
This document specifies the behavior that is expected from the DomainName System with regard to DNS queries for names ending with'.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. |
|
| |
| RFC 8376 | Low-Power Wide Area Network (LPWAN) Overview |
| |
| Authors: | S. Farrell, Ed.. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8376 |
|
Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set ofLPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of runningIP in LPWANs. |
|
| |
| RFC 8377 | Transparent Interconnection of Lots of Links (TRILL): Multi-Topology |
| |
|
|
This document specifies extensions to the IETF TRILL (TransparentInterconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS(Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177. |
|
| |
| RFC 8378 | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
| Authors: | V. Moreno, D. Farinacci. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8378 |
|
When multicast sources and receivers are active at Locator/IDSeparation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
|
| |
| RFC 8379 | OSPF Graceful Link Shutdown |
| |
| Authors: | S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8379 |
|
When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.
It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.
This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3. |
|
| |
| RFC 8380 | Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation |
| |
| Authors: | L. Dunbar, D. Eastlake 3rd, R. Perlman. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8380 |
|
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection ofLots of Links) encapsulation with assistance from a directory service. |
|
| |
| RFC 8381 | Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol |
| |
| Authors: | D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8381 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges(Routing Bridges). TRILL includes a general mechanism, called anRBridge Channel, for the transmission of typed messages betweenRBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor- specific messages over the RBridge Channel facility. |
|
| |
| RFC 8382 | Shared Bottleneck Detection for Coupled Congestion Control for RTP Media |
| |
| Authors: | D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth. |
| Date: | June 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8382 |
|
This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. |
|
| |
| RFC 8383 | Transparent Interconnection of Lots of Links (TRILL): Address Flush Message |
| |
| Authors: | W. Hao, D. Eastlake 3rd, Y. Li, M. Umair. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8383 |
|
The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane.In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.
This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets.This is a supplement to the TRILL automatic address forgetting (seeSection 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change. |
|
| |
| RFC 8384 | Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes |
| |
| Authors: | R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao. |
| Date: | July 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8384 |
|
This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "SmartEndnode". Only the attached edge RBridge can distinguish a "SmartEndnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that areFine-Grained Label (FGL) aware. |
|
| |
| RFC 8385 | Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS |
| |
| Authors: | M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8385 |
|
This document specifies methods to interconnect multiple TRILL(Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (VirtualPrivate LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. |
|
| |
| RFC 8386 | Privacy Considerations for Protocols Relying on IP Broadcast or Multicast |
| |
| Authors: | R. Winter, M. Faath, F. Weisshaar. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8386 |
|
A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content.Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols. |
|
| |
| RFC 8387 | Practical Considerations and Implementation Experiences in Securing Smart Object Networks |
| |
| Authors: | M. Sethi, J. Arkko, A. Keranen, H. Back. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8387 |
|
This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches. |
|
| |
| RFC 8388 | Usage and Applicability of BGP MPLS-Based Ethernet VPN |
| |
| Authors: | J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8388 |
|
This document discusses the usage and applicability of BGP MPLS-basedEthernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. |
|
| |
| RFC 8389 | Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) |
| |
| Authors: | Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8389 |
|
This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols. |
|
| |
| RFC 8390 | RSVP-TE Path Diversity Using Exclude Route |
| |
| Authors: | Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed.. |
| Date: | July 2018 |
| Formats: | txt html json |
| Updates: | RFC 4874 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8390 |
|
RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit ExclusionRoute Subobject (EXRS).
For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing(reference) LSP, before the new path is established, is not considered. |
|
| |
| RFC 8391 | XMSS: eXtended Merkle Signature Scheme |
| |
| Authors: | A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8391 |
|
This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifiesWinternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block.XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. |
|
| |
| RFC 8392 | CBOR Web Token (CWT) |
| |
| Authors: | M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8392 |
|
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR ObjectSigning and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token(JWT) but uses CBOR rather than JSON. |
|
| |
| RFC 8393 | Operating the Network Service Header (NSH) with Next Protocol "None" |
| |
| Authors: | A. Farrel, J. Drake. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8393 |
|
This document describes a network that supports Service FunctionChaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a newNSH "Next Protocol" type value of "None".
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case. |
|
| |
| RFC 8394 | Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements |
| |
| Authors: | Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8394 |
|
In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.
One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements. |
|
| |
| RFC 8395 | Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels |
| |
| Authors: | K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan. |
| Date: | June 2018 |
| Formats: | txt html json |
| Updates: | RFC 4761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8395 |
|
This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks(L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. |
|
| |
| RFC 8396 | Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework |
| |
| Authors: | J. Peterson, T. McGarry. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8396 |
|
The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, includingTelephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used byInternet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of theInternet environment and proposes a framework for Internet-based services relying on TNs. |
|
| |
| RFC 8397 | Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames |
| |
| Authors: | M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8397 |
|
TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus. |
|
| |
| RFC 8398 | Internationalized Email Addresses in X.509 Certificates |
| |
| Authors: | A. Melnikov, Ed., W. Chuang, Ed.. |
| Date: | May 2018 |
| Formats: | txt html json |
| Updates: | RFC 5280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8398 |
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer AlternativeName extension that allows a certificate subject to be associated with an internationalized email address.
This document updates RFC 5280. |
|
| |
| RFC 8399 | Internationalization Updates to RFC 5280 |
| |
|
|
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates. |
|
