2017-08-21, rev -04: This document defines a YANG data model for the management of hardware on a single server.
2017-08-21, rev -00: This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277.
2017-08-21, rev -00: 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). This document obsoletes RFC 7223.
2017-08-21, rev -01: For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a data model for configuring and managing the NAT is essential. This document defines a YANG data model for the NAT function.
2017-08-21, rev -00: The use of large-scale IP address sharing technologies (commonly known as "carrier-grade NAT") presents a challenge for law enforcement agencies due to the fact that incoming source port information is not routinely logged by Internet-facing servers. The absence of this information means that it is becoming increasingly difficult for law enforcement agencies to identify suspects in criminal activity online. This document considers the reasons why source port information is not routinely logged by Internet-facing servers and proposes some immediate-term actions that can be taken to help improve the situation. A deployment maturity model has been developed and a study of the support for logging incoming source port information in common server software is also presented.
2017-08-21, rev -04: The cryptographic algorithm and key size requirements included when DKIM was designed in the last decade are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimaly suitable for operation with currently specified algorithms.
2017-08-21, rev -05: 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-08-21, rev -07: This document describes a profile for the use of the Precision Time Protocol in an IPV4 or IPv6 Enterprise information system environment. The profile uses the End to End Delay Measurement Mechanism, allows both multicast and unicast Delay Request and Delay Response Messages.
2017-08-21, rev -04: As currently designed and implemented, the RPC-over-RDMA protocol requires use of multiple internode round trips to process some common operations. For example, NFS WRITE operations require use of three internode round trips. This document looks at this issue and discusses what can and what should be done to address it, both within the context of an extensible version of RPC-over-RDMA and potentially outside that framework.
2017-08-21, rev -06: Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to MPLS data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with a Segment Routing header.
2017-08-21, rev -06: 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-08-21, rev -00: Various link attributes have been defined in OSPFv2 in the context of the MPLS Traffic Engineering (TE) and GMPLS. Many of these link attributes can be used for purposes other than MPLS Traffic Engineering or GMPLS. This documents defines how to distribute such attributes in OSPFv2 for applications other than MPLS Traffic Engineering or GMPLS purposes.
2017-08-21, rev -06: This draft describes the application of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL).
2017-08-21, rev -07: TACACS+ provides Device Administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document describes the protocol that is used by TACACS+.
2017-08-21, rev -05: 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".
2017-08-21, rev -06: This document defines YANG data models for the DS-Lite Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements .
2017-08-20, rev -02: This memo defines an allocation for the Context Headers of the Network Service Header (NSH), which incorporates the packet's timestamp, a sequence number, and a source interface identifier.
2017-08-20, rev -12: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call.
2017-08-20, rev -08: Providing rapid visibility into changes made on YANG configuration and operational objects enables new capabilities such as remote mirroring of configuration and operational state. Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore.
2017-08-19, rev -03: This document outlines an approach to mitigate negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions affected by the maintenance are forcefully torn down before the actual maintenance activities commence.
2017-08-19, rev -09: This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.
2017-08-18, rev -08: This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in IS-IS and OSPF protocols.
2017-08-18, rev -00: This document defines Dynamic Host Configuration Protocol and Dynamic Host Configuration Protocol version 6 (DHCPv6) Options for LWM2M client bootstrap information, which are used to carry Uniform Resource Locater of LWM2M bootstrap server and certificate that validates the public key presented by server.
2017-08-18, rev -03: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification.
2017-08-18, rev -04: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm.
2017-08-18, rev -00: Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link.
2017-08-18, rev -06: The JSON Web Binding (JWB) describes a standardized approach to implementing Web Services. Services are advertised using the DNS SRV and HTTP Well Known Service conventions. Messages may be authenticated or authenticated and encrypted at the message layer in addition to any transport and/or network layer security. Service messages are encoded in JSON using Internet time format for Date-Time fields and Base64urlencoding for binary objects.
2017-08-18, rev -03: The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices.
2017-08-18, rev -05: The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.
2017-08-18, rev -01: Mesh/SSH
2017-08-18, rev -01: The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the use of the Mesh to store Web application information.
2017-08-18, rev -14: This document defines the multipart/multilingual content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.
2017-08-18, rev -07: This document provides a recommended default allocation for the Network Service Header (NSH) MD Type 1 fixed length context header when NSH is used for Service Function Chaining within a data center.
2017-08-18, rev -00: This document proposes a method to provide end to end security to Attributes in RADIUS Messages.
2017-08-18, rev -04: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the layering of IPv6 on 802.11 OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer.
2017-08-17, rev -06: This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.
2017-08-17, rev -00: This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction.
2017-08-17, rev -01: This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS.
2017-08-17, rev -09: This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the nornative decoder implementation included in the appendix of RFC 6716. The changes fixes real and potential security-related issues, as well minor quality-related issues.
2017-08-17, rev -05: 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 on the example scenario, analyzing the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.
2017-08-17, rev -04: This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.
2017-08-17, rev -00: This document describes a new LCAF for LISP, the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses.
2017-08-16, rev -02: This document contains a specification of YANG modules for the management of SAVI (Source Address Validation Improvements) protocol.
2017-08-16, rev -00: Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value.
2017-08-16, rev -08: 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.
2017-08-16, rev -06: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.
2017-08-16, rev -03: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration.
2017-08-16, rev -05: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC.
2017-08-16, rev -01: Mesh Confirmation Protocol (Mesh/Confirm) is a three-party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes. The three parties in the protocol are Enquirer who posts a confirmation request, a Responder who may or may not respond to the request and the Broker which provides a repository to which requests and responses are posted.
2017-08-16, rev -02: independent
2017-08-16, rev -02: Network Virtualization Overlay (NVO) networks using EVPN as control plane may use ingress replication (IR) or PIM-based trees to convey the overlay BUM traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks.
2017-08-16, rev -05: This document describes loss detection and congestion control mechanisms for QUIC.
2017-08-16, rev -01: Trust Anchor Locators (TALs) [RFC7730] are used by Relying Parties in the RPKI to locate and validate Trust Anchor certificates used in RPKI validation. This document defines an RPKI signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be published by Trust Anchor to communicate a new TAL to already deployed Relying Parties. The two primary use cases for this are that 1) a Trust Anchor may wish to change the locations where its TA certificate may be found, and 2) a Trust Anchor may wish to perform a planned migration to a new key. Note that unplanned key rolls are considered out of scope for this document.
2017-08-16, rev -06: This document defines the requirements which individual pNFS layout types need to meet in order to work within the parallel NFS (pNFS) framework as defined in RFC5661. In so doing, it aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. In this regard, this document effectively updates RFC5661.
2017-08-16, rev -04: The IPv6 Neighbor Discovery (ND) protocol allows nodes to discover neighbors on the same link. Router Advertisement (RA) messages can also convey routing information by including 1) a non-zero (default) Router Lifetime, and/or 2) Route Information Options (RIOs). This document specifies backward-compatible extensions that permit nodes to include RIOs in other IPv6 ND messages to support the discovery of more-specific routes.
2017-08-16, rev -01: This document specifies a YANG module that contains metadata related to YANG modules and vendor implementations of those YANG modules.
2017-08-15, rev -09: The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP) with global network address and multiplexing local network address. This AEIP with Network Address Multiplexing(AEIP NAM) can realize autonomy and extensibility with minimal cost.
2017-08-15, rev -08: The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP). It mainly adopts local network address based on per Autonomous IP network and uses bilateral dynamic NAT with global network address between Autonomous IP networks to solve IP address deficient problem. This AEIP with Network Address Translation(AEIP NAT) can realize autonomy and extensibility with minimal cost.
2017-08-15, rev -01: BANdwidth Aggregation for interNet Access (BANANA) makes use of a subscriber's multiple points of attachment to the Internet to provide the subscriber with higher bandwidth and reliability than what is provided by any single one of these attachments.