RFC Abstracts
RFC7755 - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
RFC7754 - Technical Considerations for Internet Service Blocking and Filtering
The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.
RFC7753 - Port Control Protocol (PCP) Extension for Port-Set Allocation
In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.
RFC7752 - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
RFC7751 - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.
RFC7750 - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)
This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.
RFC7749 - The "xml2rfc" Version 2 Vocabulary
This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.
RFC7748 - Elliptic Curves for Security
This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.
RFC7747 - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence
BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.
RFC7746 - Label Switched Path (LSP) Self-Ping
When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
RFC7745 - XML Schemas for Reverse DNS Management
This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.
RFC7744 - Use Cases for Authentication and Authorization in Constrained Environments
Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
RFC7743 - Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.
RFC7742 - WebRTC Video Processing and Codec Requirements
This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.
RFC7741 - RTP Payload Format for VP8 Video
This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.
RFC7740 - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.
RFC7739 - Security Implications of Predictable Fragment Identification Values
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.
RFC7738 - A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)
This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).
RFC7737 - Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.
RFC7736 - Content Delivery Network Interconnection (CDNI) Media Type Registration
This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.
RFC7735 - Tracking Reviews of Documents
Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.
RFC7734 - Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.
RFC7733 - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.
RFC7732 - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.
RFC7731 - Multicast Protocol for Low-Power and Lossy Networks (MPL)
This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.
RFC7730 - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.
RFC7729 - Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management
Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.
RFC7728 - RTP Stream Pause and Resume
With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.
RFC7727 - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.
RFC7726 - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)
This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.
RFC7725 - An HTTP Status Code to Report Legal Obstacles
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.
RFC7724 - Active DHCPv4 Lease Query
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".
RFC7723 - Port Control Protocol (PCP) Anycast Addresses
The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.
RFC7722 - Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
RFC7721 - Security and Privacy Considerations for IPv6 Address Generation Mechanisms
This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.
RFC7720 - DNS Root Name Service Protocol and Deployment Requirements
The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.
RFC7719 - DNS Terminology
The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
RFC7718 - Registries for the One-Way Active Measurement Protocol (OWAMP)
This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.
RFC7717 - IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.
RFC7716 - Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.
RFC7715 - Multipoint LDP (mLDP) Node Protection
This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.
RFC7714 - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).
RFC7713 - Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.
RFC7712 - Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.
RFC7711 - PKIX over Secure HTTP (POSH)
Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.
RFC7710 - Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.
RFC7709 - Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)
Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.
RFC7708 - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).
RFC7707 - Network Reconnaissance in IPv6 Networks
IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.
RFC7706 - Decreasing Access Time to Root Servers by Running One on Loopback
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.
This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
RFC7754 - Technical Considerations for Internet Service Blocking and Filtering
The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.
RFC7753 - Port Control Protocol (PCP) Extension for Port-Set Allocation
In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.
RFC7752 - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
RFC7751 - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.
RFC7750 - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)
This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.
RFC7749 - The "xml2rfc" Version 2 Vocabulary
This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.
RFC7748 - Elliptic Curves for Security
This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.
RFC7747 - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence
BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.
RFC7746 - Label Switched Path (LSP) Self-Ping
When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
RFC7745 - XML Schemas for Reverse DNS Management
This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.
RFC7744 - Use Cases for Authentication and Authorization in Constrained Environments
Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
RFC7743 - Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.
RFC7742 - WebRTC Video Processing and Codec Requirements
This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.
RFC7741 - RTP Payload Format for VP8 Video
This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.
RFC7740 - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.
RFC7739 - Security Implications of Predictable Fragment Identification Values
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.
RFC7738 - A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)
This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).
RFC7737 - Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.
RFC7736 - Content Delivery Network Interconnection (CDNI) Media Type Registration
This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.
RFC7735 - Tracking Reviews of Documents
Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.
RFC7734 - Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.
RFC7733 - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.
RFC7732 - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.
RFC7731 - Multicast Protocol for Low-Power and Lossy Networks (MPL)
This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.
RFC7730 - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.
RFC7729 - Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management
Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.
RFC7728 - RTP Stream Pause and Resume
With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.
RFC7727 - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.
RFC7726 - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)
This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.
RFC7725 - An HTTP Status Code to Report Legal Obstacles
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.
RFC7724 - Active DHCPv4 Lease Query
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".
RFC7723 - Port Control Protocol (PCP) Anycast Addresses
The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.
RFC7722 - Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
RFC7721 - Security and Privacy Considerations for IPv6 Address Generation Mechanisms
This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.
RFC7720 - DNS Root Name Service Protocol and Deployment Requirements
The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.
RFC7719 - DNS Terminology
The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
RFC7718 - Registries for the One-Way Active Measurement Protocol (OWAMP)
This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.
RFC7717 - IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.
RFC7716 - Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.
RFC7715 - Multipoint LDP (mLDP) Node Protection
This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.
RFC7714 - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).
RFC7713 - Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.
RFC7712 - Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.
RFC7711 - PKIX over Secure HTTP (POSH)
Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.
RFC7710 - Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.
RFC7709 - Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)
Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.
RFC7708 - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).
RFC7707 - Network Reconnaissance in IPv6 Networks
IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.
RFC7706 - Decreasing Access Time to Root Servers by Running One on Loopback
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.