2017-04-28, rev -06: This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology needed for measuring the compression efficiency to ensure whether the stated requirements are fulfilled or not.
2017-04-28, rev -12: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.
2017-04-28, rev -03: This document defines a YANG data model for BIER TE configuration and operation.
2017-04-28, rev -01: RADIUS contains a one-octet Identifier field which is used to correlate requests and replies. This field limits the number of outstanding requests to 256. Experience shows that this limitation is problematic for high load systems. This document proposes to use the Request Authenticator field as an additional unique identifier. The replies can then be correlated to requests by copying the Request Authenticator from the request to a new attribute in the response, called the Original-Request-Authenticator.
2017-04-28, rev -01: This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries. As a result, this document updates many RFCs (see updates header).
2017-04-28, rev -01: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor.
2017-04-28, rev -04: Encrypted Key Transport (EKT) is an extension to DTLS and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints.
2017-04-28, rev -12: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
2017-04-28, rev -06: This document specifies a Password Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.
2017-04-28, rev -00: This document specifies Regional Routing Protocol, sometimes referred to as KHALED Routing Protocol (KRP).
2017-04-28, rev -22: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.
2017-04-28, rev -04: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic contexts to provide "hop-by-hop" and "end-to-end" security guarantees. Both the end-to-end and hop-by-hop cryptographic transforms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties.
2017-04-28, rev -06: This document describes Schnorr NIZK proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure the participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.
2017-04-28, rev -05: The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications, these applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms.
2017-04-28, rev -00: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
2017-04-28, rev -02: This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future.
2017-04-28, rev -20: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
2017-04-27, rev -05: Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network or can they merely be unique within each multilevel area?
2017-04-27, rev -03: This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, and provide enhancements to the registration capabilities, in particular for the registration to a Backbone Router for proxy ND operations.
2017-04-27, rev -23: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route.
2017-04-27, rev -03: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, to enable a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.
2017-04-27, rev -04: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session.
2017-04-27, rev -04: This draft describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with three new capabilities: support for multi-protocol encapsulation, operations, administration and management (OAM) signaling and explicit versioning.
2017-04-27, rev -15: This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases.
2017-04-27, rev -04: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.
2017-04-27, rev -10: The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints.
2017-04-27, rev -10: This document defines the Information Elements that are transported between SACM components and their interconnected relationships. The primary purpose of the Secure Automation and Continuous Monitoring (SACM) Information Model is to ensure the interoperability of corresponding SACM data models and addresses the use cases defined by SACM. The Information Elements and corresponding types are maintained as the IANA "SACM Information Elements" registry.
2017-04-27, rev -03: In support of Segment Routing (SR) routing protocols advertise a variety of identifiers used to define the segments which direct forwarding of packets. In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required. This document defines the policies used to resolve these occurrences.
2017-04-27, rev -06: The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.
2017-04-26, rev -31: This document tries to propose an architectural framework of the internet in the real IP world. It shows how to reorganize the provider network with a large address space. It describes how a three-tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and some sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6.
2017-04-26, rev -04: The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center.
2017-04-26, rev -07: The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network switches and routers in the data center.
2017-04-26, rev -02: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols.
2017-04-26, rev -04: This document defines an extension to the Locator/ID Separation Protocol (LISP) to minimize LISP service disruption during Ingress Tunnel Routers (ITRs) failure events.
2017-04-26, rev -04: The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
2017-04-26, rev -05: This document extends Locator/ID Separation Protocol (LISP) with a capability for bulk mapping retrieval. It does so by defining new LISP messages that are meant to facilitate state recovery of mapping tables and improve Ingress Tunnel Routers (ITR) recovery times, in particular. In addition, this document allows to request mappings that match destination IP prefixes, names, or AS numbers.
2017-04-26, rev -05: Mapping Services in Locator/ID Separation Protocol (LISP) networks are key to proper LISP forwarding operation. When considering the deployment of LISP at large scale, these Mapping Services are even more crucial for the sake of the LISP forwarding efficiency. This document introduces two additional LISP messages that are meant to facilitate the dynamic discovery of Mapping Systems, improve Ingress Tunnel Routers (ITR) recovery times and optimize the solicitation of the LISP Mapping System as a function of the ITR location, in particular.
2017-04-26, rev -01: This document describes work conducted at the 3GPP standard organization on 5G Network Slicing. Its goal is to provide detailed use cases, and help better define requirements, for Internet Protocols supporting Network Slicing.
2017-04-26, rev -00: This document specifies transport independent capabilities for messages transporting event notifications and YANG datastore update records. Included are:
2017-04-26, rev -10: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice.
2017-04-26, rev -04: This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374.
2017-04-26, rev -41: This document provides a solution for Site Multihoming of stub networks in a real IP environment. Each user interface in a customer network may have as many global unicast addresses as many service providers it will be connected with. Users can establish multiple connections through different service providers simultaneously. Customer networks can maintain private address space to communicate within its users. Customer networks can provide IP mobility services as well.
2017-04-25, rev -03: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.
2017-04-25, rev -04: This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- email@example.com.
2017-04-25, rev -10: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- firstname.lastname@example.org.
2017-04-25, rev -03: This document defines a new IS-IS TLV which carries the Geo Coordinates information of the system. The Geo Coordinates information can be used by IS-IS routing or by any applications.
2017-04-25, rev -03: 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 (PW) using LSP Ping.
2017-04-25, rev -06: In some scenarios, MPLS Transport Profile (MPLS-TP) Pseudowires (PWs) (RFC 5921) may be statically configured, when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in [draft-ietf-pals-mpls-tp- dual-homing-protection]. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs, which is used for state exchange and switchover coordination between the dual-homing PEs for dual-homing PW local protection.
2017-04-25, rev -06: This document describes a framework and several scenarios for a Pseudowire (PW) dual-homing local protection mechanism which avoids unnecessary switchovers and which can be used for scenarios using a control plane or not using a control plane. A Dual-Node Interconnection (DNI) PW is used for carrying traffic between the dual-homing Provider Edge (PE) nodes for carrying traffic when a failure occurs in one of the Attachment Circuits (AC) or PWs. This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.
2017-04-25, rev -06: This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a compact, and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys that can be used over any layer. EDHOC messages are encoded with CBOR and COSE, allowing reuse of existing libraries.
2017-04-25, rev -05: This document proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6.
2017-04-25, rev -01: An abstract data model for HTTP headers, "Common Structure", and a HTTP/1 serialization of it, generalized from current HTTP headers.
2017-04-25, rev -01: This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965.
2017-04-25, rev -00: This document specifies KHALED Routing Protocol (KRP).
2017-04-25, rev -20: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures.
2017-04-25, rev -01: This draft describes a method of inserting Key Performance Indicators (KPIs) into Network Service Header (NSH) encapsulated packets or frames on service chains. This method may be used to monitor latency and QoS configuration to identify problems with virtual links (vlinks), Virtual Network Functions (VNFs) or Physical Network Functions (PNFs) on the Rendered Service Path (RSP).
2017-04-25, rev -05: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests.
2017-04-25, rev -01: The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations.
2017-04-25, rev -03: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees.