2017-10-18, rev -04: This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client sponsored objects that were not initiated by the client through EPP. These operations MAY include contractual or policy requirements including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why.
2017-10-18, rev -00: This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path.
2017-10-18, rev -03: It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken.
2017-10-18, rev -10: 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. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network, or with slight differences, in a non-MPLS network.
2017-10-18, rev -01: This document describes several potential performance scalability and capability issues when implementing in-situ OAM on heterogenous target network elements. The document proposes the corresponding solutions and modifications to the current in-situ OAM specification to mitigate the issues. Specifically, in-situ OAM is extended with data validation fields to cope with the node processing capability. We provide use cases to motivate our proposal and base the modifications on the current in-situ OAM header format specification.
2017-10-18, rev -04: This draft describes Network Service Header (NSH) MD-Type 2 metadata TLVs that can be used within a service function path.
2017-10-18, rev -01: This document describes the problems associated with the use of No- Path DAO messaging in RPL and a signaling changes to improve route invalidation efficiency.
2017-10-18, rev -05: This document specifies an OSPF Router Information (RI) TLV to advertise the current Geo Coordinates of the OSPF router. For Point- to-Point (P2P)) and Point-to-Multi-Point (P2MP) networks, the Geo Coordinates can be used to dynamically computing the cost to neighbors. This is useful both from the standpoint of auto- configuration and situations where the OSPF routers are moving. The Geo Coordinates are also useful for other applications such as Traffic Engineering (TE) and network management.
2017-10-18, rev -00: The following document describes a DNS-based mechanism for a client to discover an OpenID Identity Provider given an Identifier of the End-User, as a complementary alternative to the existing WebFinger- based mechanism.
2017-10-18, rev -00: This document describes the distributed data collection mechanism that allows multiple data streams to be managed using a single subscription. Specifically, multiple data streams are pushed directly to the collector without passing through a broker for internal consolidation.
2017-10-18, rev -04: 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 MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets.
2017-10-18, rev -00: This document provides a problem statement, derives an initial gap analysis and illustrates a first set of solution approaches in regard to augmenting YANG data stores based on the CoAP Management Interface with YANG Push capabilities. A binary transfer mechanism for YANG Subscribed Notifications addresses both the requirements of constrained-node networks and the need for semantic interoperability via self-descriptiveness of the corresponding data in motion.
2017-10-17, rev -06: This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.
2017-10-17, rev -03: This document presents the China Education and Research Network (CERNET)'s IPv4 as a Service (IPv4aaS) design, deployment and operation experience.
2017-10-17, rev -00: This document describes a proposal to segment an in-situ OAM domain in order to control the iOAM data overhead, adapt to the path MTU limitations, and enable new applications. We provide use cases to motivate our proposal and base the necessary modifications on the current in-situ OAM header format specification.
2017-10-17, rev -07: The stateless translator can support IPv6-initiated communications as well as IPv4-initiated communications for IPv6 hosts using IPv4- translatable addresses. DNS support for the IPv6-initiated communication is defined in the DNS64 specification. This document defines the DNS46 function for the stateless translator.
2017-10-17, rev -09: In the context of BGPsec, a withdrawal suppression occurs when an adversary AS suppresses a prefix withdrawal with the intension of continuing to attract traffic for that prefix based on a previous (signed and valid) BGPsec announcement that was earlier propagated. Subsequently if the adversary AS had a BGPsec session reset with a neighboring BGPsec speaker and when the session is restored, the AS replays said previous BGPsec announcement (even though it was withdrawn), then such a replay action is called a replay attack. The BGPsec protocol should incorporate a method for protection from Replay Attack and Withdrawal Suppression (RAWS), at least to control the window of exposure. This informational document provides design discussion and comparison of multiple alternative RAWS protection mechanisms weighing their pros and cons. This is meant to be a companion document to the standards track draft-ietf-sidrops-bgpsec- rollover that will specify a method to be used with BGPsec for RAWS protection.
2017-10-17, rev -05: Existing IP-in-IP encapsulation technologies are not adequate for efficient load balancing of IP-in-IP traffic across IP networks. This document specifies additional IP-in-IP encapsulation technology, referred to as IP-in-UDP (User Datagram Protocol), which can facilitate the load balancing of IP-in-IP traffic across IP networks.
2017-10-17, rev -07: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing when applied to the MPLS dataplane.
2017-10-17, rev -11: This document discusses an extension of the algorithmic translation between IPv4 and IPv4-translatable IPv6 addresses. The extended address format contains transport-layer port set identification (PSID) which allows several IPv6 nodes to share a single IPv4 address with each node managing a different range of ports. This address format extension can be used for IPv4/IPv6 translation, as well as IPv4 over IPv6 tunneling.
2017-10-17, rev -01: The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including those related to structure, organization, personnel, and transparency.
2017-10-17, rev -02: This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents, in reference to what is the actual functionalities being used (not the actual protocol support).
2017-10-17, rev -00: This document describes a proposal which extends in-situ OAM to support potential future standard tracing data in addition to those currently defined. We provide use cases to motivate our proposal and base the modifications on the latest in-situ OAM header format specification.
2017-10-17, rev -01: This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required.
2017-10-17, rev -13: A Segment Routing architecture leverages source routing and tunneling paradigms and can be directly applied to use of a Multi Protocol Label Switching (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-10-17, rev -09: This document presents the testing results of a unified code accommodating encapsulation and translation modes of Mapping of Address and Port (MAP). Experiments show that the unified MAP CE is not only supporting MAP-E and MAP-T modes, but also backward compatible with AFTR of dual-stack lite and stateless/stateful NAT64.
2017-10-17, rev -02: This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide a set of guidance for DOTS clients/gateways when multihomed.
2017-10-17, rev -01: For C-ACC, platooning and other typical use cases in ITS, direct IP communication between neighbor vehicles poses the following two issues: 1) how to discover the neighbor vehicle and the demanded service; and 2) how to discover the link-layer address of the neighbor vehicle and selected server. This draft presents a solution to these problems based on DNS-SD/mDNS [RFC6762][RFC6763].
2017-10-17, rev -07: Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging source routing. The ingress node prepends a SR header to a packet containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is maintained only at the ingress node of the SR domain.
2017-10-17, rev -05: This memo defines a portion of the Management Information Base (MIB), the SYSLOG-MIB, for use with network management protocols in the Internet community. In particular, the SYSLOG-MIB will be used to monitor and control syslog applications.
2017-10-17, rev -01: This document specifies the transition requirements for an IPv6 Customer Edge (CE) router. Specifically, this document extends the "Basic Requirements for IPv6-only Customer Edge Routers" ([RFC7084]) in order to allow the provisioning of IPv6 transition services for the hosts attached to it. The document covers several transition technologies, either for delivering IPv6 in IPv4-only access networks and specially for delivering IPv4 "as-a-service" as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so.
2017-10-17, rev -03: This document defines a YANG module for a system-level mechanism, called a "keystore", containing security-sensitive data including private keys, pinned certificates, and pinned SSH host-keys.
2017-10-17, rev -05: This document defines YANG modules for the Port Control Protocol (PCP), including PCP client, PCP server, PCP proxy, and Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function.
2017-10-17, rev -18: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its preconfigured initial state (e.g., factory default settings), and its deployment specific network management system (NMS).
2017-10-17, rev -08: This document presents the concepts and the implementations of address-sharing dual-stateless IPv4/IPv6 translation (dIVI).
2017-10-16, rev -10: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
2017-10-16, rev -05: This document defines a YANG data model for the management of hardware on a single server.
2017-10-16, 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-10-16, 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-10-16, rev -02: This draft defines procedures and messages for BGP SRv6-based L3VPN and EVPN. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and "RFC7432 "BGP MPLS-Based Ethernet VPN" and provides a migration path from MPLS-based VPNs to SRv6 based VPNs.
2017-10-16, rev -00: This document defines an extensible method to return additional information about the cause of DNS errors. The primary use case is to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures.
2017-10-16, rev -05: This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy.
2017-10-16, rev -09: Traffic Engineered networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking.
2017-10-16, rev -06: EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used.
2017-10-16, rev -15: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. This document considers the case when the requesting router is a node that acts as a host on behalf of its local applications and as a router on behalf of any downstream networks.
2017-10-16, rev -05: 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-10-16, rev -04: This draft provides an information model for Abstraction and Control of Traffic Engineered (TE) networks (ACTN).
2017-10-16, rev -08: The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new 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. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network.
2017-10-16, rev -02: 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-10-16, rev -05: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security of CoAP (OSCOAP) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.
2017-10-16, rev -01: When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This is solved by advertising cross-address family (X-AF) OSPF TE information.
2017-10-16, rev -05: The Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.
2017-10-16, rev -04: This Internet-Draft describes SPAKE2, a secure, efficient password based key exchange protocol.
2017-10-16, rev -06: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. It contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC trust anchor, and using RFC5011 to update that trust anchor, you probably don't need to read this document.
2017-10-16, rev -01: This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by a BGP-LS speaker. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels needs to know the MSD supported by the head-end at node and/or link granularity to push the SID stack of an appropriate depth. MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack.
2017-10-16, rev -00: This document describes a simple extension to RDAP and an operational model for network operators to serve RDAP network information using statically generated JSON files over HTTPS.
2017-10-16, rev -11: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, 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-10-16, rev -13: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.
2017-10-16, rev -00: This document addresses the topic of unrequested traffic in the form of spam or DDoS attacks. Instead of solely discussing these topics from a mere technical angle, it also addresses human rights implications of unrequested traffic.
2017-10-16, rev -02: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them.