2017-06-23, rev -03: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit.
2017-06-23, rev -07: This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined.
2017-06-23, rev -02: This document describes an Extensible Provisioning Protocol (EPP) extension for including an allocation token or code for allocating an object like a domain name to the client. The allocation token MAY be transferred out-of-band to a client to give them authorization to allocate an object using one of the EPP transform commands including create, update, and transfer.
2017-06-23, rev -02: 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-06-23, rev -02: This document defines identity modules based on Secure Elements processing DTLS/TLS stacks for CoAP devices. The expected benefits of these secure microcontrollers are the following : - Secure storage of pre-share keys or private keys - Trusted simple or mutual authentication between CoAP devices and CoAP clients. - The device identity is enforced by a non cloneable chip. - Trusted cryptographic support. - Low power consumption for DTLS/TLS processing.
2017-06-23, rev -01: This draft provides an information model for Abstraction and Control of Traffic Engineered (TE) networks (ACTN).
2017-06-23, rev -02: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates.
2017-06-23, rev -17: Segment Routing (SR) allows 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-06-23, rev -05: 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-06-23, rev -00: This document extends the Path Communication Element Communication Protocol (PCEP) to coordinate an end-to-end inter-domain tunnel setup over a multi-domain networks in the context of Hierarchical Stateful PCE environments. This document uses Stitching Label (SL) to stich per-domain LSPs.
2017-06-23, rev -00: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected.
2017-06-23, rev -00: The IETF has produced a considerable number of data modules in the YANG modelling language. The majority of these modules are used to construct data models to model devices or monolithic functions and they allow access for configuration and to read operational status.
2017-06-22, rev -06: This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. SFs are expected to be defined in future companion specifications.
2017-06-22, rev -04: This document describes an autonomic solution 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-06-22, rev -00: Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the BGP-Nexthop attribute (code 3), or inside the MP_REACH attribute (code 14).
2017-06-22, rev -00: The MPLS-forwarding-layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node.
2017-06-22, rev -01: Segment Routing architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems. This document defines how to use Label Switched Path Ping to bootstrap and control path in reverse direction of a BFD session on the Segment Routing static MPLS tunnel.
2017-06-22, rev -07: This Internet Draft presents a specification for Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050.
2017-06-22, rev -00: This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called "custody transfer". This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050.
2017-06-22, rev -19: The purpose of this informational document is to establish definitions and describe measurement techniques for data center benchmarking, as well as it is to introduce new terminologies applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and, is a pre-requisite to the test methodology publication [draft-ietf-bmwg-dcbench-methodology]. Many of these terms and methods may be applicable to network equipment beyond this publication's scope as the technologies originally applied in the data center are deployed elsewhere.
2017-06-22, rev -02: 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-06-22, rev -12: The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network"). This document discusses how those functional requirements can be easily met with Ethernet VPN (EVPN) and how EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly.
2017-06-22, rev -01: This document aims to scope the relation between Internet protocols and the rights to freedom of assembly and association. The Internet increasingly mediates our lives and our ability to excercise human rights. Since Internet protocols play a central role in the management, development and use of the Internet, the relation between the mentioned rights should be documented and adverse impacts should be mitigated. As there have been methods of protest on the Internet -a form of freedom of assembly- that have proven to be harmful to connectivity and infrastructure, such as DDoS attacks, this text aims to document forms of protest, association and assembly that do not have a negative impact on the Internet infrastructure.
2017-06-22, rev -07: This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions.
2017-06-22, rev -00: The MarNEW workshop aimed to discuss solutions for badnwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's internet users. The workshop gathered IETF attendees, IAB members and various organisations involved in the telecommunications industry including original equipment manufacturers and mobile network operators.
2017-06-22, rev -03: The MarNEW workshop aimed to discuss solutions for badnwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's internet users. The workshop gathered IETF attendees, IAB members and various organisations involved in the telecommunications industry including original equipment manufacturers and mobile network operators.
2017-06-22, rev -04: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits.
2017-06-22, rev -05: 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-06-22, rev -07: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253.
2017-06-22, rev -06: This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- TE) mechanism that enables the network to assign an upstream label for a bidirectional LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFC3473 as it defines processing for a special label value.
2017-06-22, rev -10: 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-06-22, rev -00: Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header.
2017-06-22, rev -03: for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks.
2017-06-22, rev -10: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS dataplane, the SR header is instantiated through a label stack. A segment can represent any instruction, topological or service-based. Additional segments can be defined in the future. SR allows to enforce a flow through any topological path and/or service chain while maintaining per-flow state only at the ingress node to the SR domain.
2017-06-22, rev -00: This document defines the .0 format, a format for transmitting data that can be efficiently parsed.
2017-06-22, rev -01: Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially the smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. As part of this technology, Narrowband PLC (NBPLC) is focused on the low- bandwidth and low-power scenarios that includes current standards such as IEEE 1901.2 and ITU-T G.9903. This document describes how IPv6 packets are transported over constrained PLC networks.
2017-06-22, rev -05: The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings for the use of RSASSA-PSS signatures, RSAES-OAEP encryption, and RSA keys are specified.
2017-06-22, rev -00: This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
2017-06-21, rev -13: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models.
2017-06-21, rev -00: Software-Defined Networks (SDNs) are multilayer systems. In this context, this draft defines a graph-based reference model capable of properly representing such complex multilayer networks. The defined reference model thus eases the management and planning of SDN environments.
2017-06-21, rev -06: 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, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network.
2017-06-21, rev -07: Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.
2017-06-21, rev -01: Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server.
2017-06-21, rev -18: The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. A pre-requisite to this publication is the terminology document [draft-ietf-bmwg-dcbench- terminology]. Many of these terms and methods may be applicable beyond this publication's scope as the technologies originally applied in the data center are deployed elsewhere.
2017-06-21, rev -01: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength.
2017-06-21, rev -02: 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-06-21, rev -03: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint.
2017-06-21, rev -01: This document proposes an Fast ReRoute (FRR) extension to the BIER-TE Architecture [I-D.eckert-bier-te-arch]. The FRR procedure has to be supported by the BIER-TE Controller host and the BFRs that are attached to a link/adjacency for which FRR support is required. Thus, the FRR concept can be incrementally deployed in the data plane to only those BFR adjacent to adjacencies for which FRR protection is desired.
2017-06-21, rev -00: IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity into networking. This concept includes an Identity/Identifier split, which complements existing Locator/Identifier separation technologies. This document summarizes some conceptual use cases to illustrate the usefulness of IDEAS.
2017-06-21, rev -04: IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce, saving 8 octets per packet. This document describes how to do this.
2017-06-21, rev -09: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.
2017-06-21, rev -05: This document describes a mechanism for link-state routing protocols to prevent local transient forwarding loops in case of link failure. This mechanism proposes a two-steps convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network wide convergence.
2017-06-21, rev -01: Based on IPv6, multiple mobility management protocols have been developed and generally they can be classified into two types: network-based and host-based. Different protocols have different functional requirements on the network element or the terminal and then a scheme should be used in order to support the negotiation and selection of adopted mobility management protocol when a terminal accesses to a new network. In this draft, this issue is considered and analyzed.
2017-06-21, rev -00: This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS).
2017-06-21, rev -07: This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). 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. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification.
2017-06-21, rev -00: RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks as the PE responsible for sending broadcast, multicast and unknown unicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing ES, or BUM and unicast in the case of single-active multi-homing.
2017-06-21, rev -01: Constrained Application Protocol (CoAP) is a application protocol for use with constrained nodes and constrained networks that is attractive to be applied In the Industrial Internet of Things (IIoT). OPC Unified Architecture (OPC UA) defines a semantic-based information model for industrial control system that can satisfy the requirements of Industry 4.0, which is based on semantic information exchange. This document analyses requirements for transmitting OPC UA over CoAP.
2017-06-21, rev -20: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.
2017-06-21, rev -00: This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft starts by listing known attacks against SNI encryption, and then presents two potential solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol.
2017-06-21, rev -11: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender.