|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 8308 |
 Extension Negotiation in the Secure Shell (SSH) Protocol
|
|
Summary Publication date: Mar 2018 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 after SSH key exchange. |
| RFC 8310 |
Usage Profiles for DNS over TLS and DNS over DTLS
|
|
Summary Publication date: Mar 2018 This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer 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 a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. |
| RFC 8328 |
Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)
|
|
Summary Publication date: Mar 2018 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 8332 |
Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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 (>50%) of the total forwarding loops. |
| RFC 8336 |
The ORIGIN HTTP/2 Frame
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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 Targeted IP 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 Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications. |
| RFC 8339 |
Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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)
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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 Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. |
| RFC 8344 |
A YANG Data Model for IP Management
|
|
Summary Publication date: Mar 2018 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 Network Management Datastore Architecture defined in RFC 8342. This document obsoletes RFC 7277. |
| RFC 8345 |
A YANG Data Model for Network Topologies
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 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)
|
|
Summary Publication date: Mar 2018 This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. |
| RFC 8348 |
A YANG Data Model for Hardware Management
|
|
Summary Publication date: Mar 2018 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)
|
|
Summary Publication date: Mar 2018 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, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. |
| RFC 8350 |
Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
|
|
Summary Publication date: Apr 2018 Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless 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 Data Channel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access 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 the WTP. |
| RFC 8351 |
The PKCS #8 EncryptedPrivateKeyInfo Media Type
|
|
Summary Publication date: Jun 2018 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
|
|
Summary Publication date: Apr 2018 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
|
|
Summary Publication date: May 2018 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 for GSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). |
| RFC 8354 |
Use Cases for IPv6 Source Packet Routing in Networking (SPRING)
|
|
Summary Publication date: Mar 2018 The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in an IPv6-only environment. |
| RFC 8355 |
Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
|
|
Summary Publication date: Mar 2018 This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks. |
| RFC 8356 |
Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)
|
|
Summary Publication date: Mar 2018 IANA assigns values to the Path Computation Element Communication Protocol (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 for PCEP 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
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Mar 2018 RFC 5485 specifies the conventions for digital signatures on Internet-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 RFC 7997 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
|
|
Summary Publication date: Mar 2018 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
|
|
Summary Publication date: Apr 2018 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 Public Key Infrastructure (RPKI), while retaining essential security features. The procedure specified in RFC 6487 requires that Resource Certificates 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 Certification Authority (CA) to chose to communicate that such Resource Certificates 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 Key Infrastructure (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 Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI 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
|
|
Summary Publication date: Apr 2018 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 ingress RBridge 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
|
|
Summary Publication date: Apr 2018 OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-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
|
|
Summary Publication date: May 2018 The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (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 in RFCs 7698 and 7699, this document describes the Open Shortest Path First - 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)
|
|
Summary Publication date: Mar 2018 Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous 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 PIM Flooding 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)
|
|
Summary Publication date: Mar 2018 This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN 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 Generic Network 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 specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices. |
| RFC 8366 |
A Voucher Artifact for Bootstrapping Protocols
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: 1 April 2018 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)
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: 1 April 2018 It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-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
|
|
Summary Publication date: May 2018 Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed. This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments. |
| RFC 8371 |
Mobile Node Identifier Types for MIPv6
|
|
Summary Publication date: Jul 2018 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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: May 2018 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 new SDP media attributes. |
| RFC 8374 |
BGPsec Design Choices and Summary of Supporting Discussions
|
|
Summary Publication date: Apr 2018 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 IETF SIDR 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.'
|
|
Summary Publication date: May 2018 This document specifies the behavior that is expected from the Domain Name 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
|
|
Summary Publication date: May 2018 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 of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. |
| RFC 8377 |
Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
|
|
Summary Publication date: Jul 2018 This document specifies extensions to the IETF TRILL (Transparent Interconnection 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
|
|
Summary Publication date: May 2018 When multicast sources and receivers are active at Locator/ID Separation 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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: May 2018 This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service. |
| RFC 8381 |
Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol
|
|
Summary Publication date: May 2018 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 an RBridge Channel, for the transmission of typed messages between RBridges 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
|
|
Summary Publication date: Jun 2018 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
|
|
Summary Publication date: May 2018 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 (see Section 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
|
|
Summary Publication date: Jul 2018 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 "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" 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 are Fine-Grained Label (FGL) aware. |
| RFC 8385 |
Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS
|
|
Summary Publication date: Jun 2018 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 (Virtual Private 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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: May 2018 This document discusses the usage and applicability of BGP MPLS-based Ethernet 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 8390 |
RSVP-TE Path Diversity Using Exclude Route
|
|
Summary Publication date: Jul 2018 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 Exclusion Route 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
|
|
Summary Publication date: May 2018 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 specifies Winternitz 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)
|
|
Summary Publication date: May 2018 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 Object Signing 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'
|
|
Summary Publication date: May 2018 This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: Jun 2018 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
|
|
Summary Publication date: Jul 2018 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, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-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 the Internet 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
|
|
Summary Publication date: May 2018 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
|
|
Summary Publication date: May 2018 This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name 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
|
|
Summary Publication date: May 2018 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. |
| RFC 8400 |
Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
|
|
Summary Publication date: Jun 2018 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). |
