| |
| RFC 7700 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames |
| |
|
|
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. |
|
| |
| RFC 7701 | Multi-party Chat Using the Message Session Relay Protocol (MSRP) |
| |
| Authors: | A. Niemi, M. Garcia-Martin, G. Sandbakken. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7701 |
|
The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and theSession Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. |
|
| |
| RFC 7702 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat |
| |
| Authors: | P. Saint-Andre, S. Ibarra, S. Loreto. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7702 |
|
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).Specifically, this document defines a mapping between the SIP-basedMessage Session Relay Protocol (MSRP) and the XMPP Multi-User Chat(MUC) extension. |
|
| |
| RFC 7703 | Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) |
| |
| Authors: | E. Cordeiro, R. Carnier, A. Moreiras. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7703 |
|
This document describes the testing result of a network utilizing aMapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.
The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines. |
|
| |
| RFC 7704 | An IETF with Much Diversity and Professional Conduct |
| |
| Authors: | D. Crocker, N. Clark. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7704 |
|
The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF. |
|
| |
| RFC 7705 | Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute |
| |
|
|
This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. |
|
| |
| RFC 7706 | Decreasing Access Time to Root Servers by Running One on Loopback |
| |
| Authors: | W. Kumari, P. Hoffman. |
| Date: | November 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8806 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7706 |
|
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. |
|
| |
| RFC 7707 | 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. |
|
| |
| RFC 7708 | Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator |
| |
| Authors: | T. Nadeau, L. Martini, S. Bryant. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7708 |
|
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 ChannelLabel 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 inMPLS Transport Profile (MPLS-TP) networks (RFC 5921). |
|
| |
| RFC 7709 | Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) |
| |
| Authors: | A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7709 |
|
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.
The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-ProtocolLabel Switching (GMPLS). |
|
| |
| RFC 7710 | Captive-Portal Identification Using DHCP or Router Advertisements (RAs) |
| |
| Authors: | W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8910 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7710 |
|
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.
This document describes a DHCP option (and a Router Advertisement(RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to getInternet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document. |
|
| |
| RFC 7711 | PKIX over Secure HTTP (POSH) |
| |
| Authors: | M. Miller, P. Saint-Andre. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7711 |
|
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 PresenceProtocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols. |
|
| |
| RFC 7712 | Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, M. Miller, P. Hancke. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7712 |
|
This document improves the security of the Extensible Messaging andPresence 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. |
|
| |
| RFC 7713 | Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements |
| |
| Authors: | M. Mathis, B. Briscoe. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7713 |
|
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 ExplicitCongestion 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. |
|
| |
| RFC 7714 | AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) |
| |
| Authors: | D. McGrew, K. Igoe. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7714 |
|
This document defines how the AES-GCM Authenticated Encryption withAssociated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-timeTransport Protocol (SRTP). |
|
| |
| RFC 7715 | Multipoint LDP (mLDP) Node Protection |
| |
| Authors: | IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7715 |
|
This document describes procedures to support node protection forPoint-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths(P2MP and MP2MP LSPs) that have been built by the Multipoint LabelDistribution Protocol (mLDP). In order to protect a node N, thePoint 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. |
|
| |
| RFC 7716 | Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures |
| |
| Authors: | J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7716 |
|
RFCs 6513, 6514, and others describe protocols and procedures that aService Provider (SP) may deploy in order to offer Multicast VirtualPrivate 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 forGlobal Table Multicast. |
|
| |
| RFC 7717 | 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 ActiveMeasurement 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. |
|
| |
| RFC 7718 | Registries for the One-Way Active Measurement Protocol (OWAMP) |
| |
|
|
This memo describes the registries for OWAMP -- the One-Way ActiveMeasurement 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. |
|
| |
| RFC 7719 | DNS Terminology |
| |
| Authors: | P. Hoffman, A. Sullivan, K. Fujiwara. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8499 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7719 |
|
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. |
|
| |
| RFC 7720 | 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. |
|
| |
| RFC 7721 | Security and Privacy Considerations for IPv6 Address Generation Mechanisms |
| |
| Authors: | A. Cooper, F. Gont, D. Thaler. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7721 |
|
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. |
|
| |
| RFC 7722 | Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This specification describes an extension to the Optimized Link StateRouting Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions. |
|
| |
| RFC 7723 | Port Control Protocol (PCP) Anycast Addresses |
| |
| Authors: | S. Kiesel, R. Penno. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7723 |
|
The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-pathNAT, 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. |
|
| |
| RFC 7724 | Active DHCPv4 Lease Query |
| |
| Authors: | K. Kinnear, M. Stapp, B. Volz, N. Russell. |
| Date: | December 2015 |
| Formats: | txt html json |
| Updates: | RFC 6926 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7724 |
|
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 withLeasequery data is sometimes desired. This document expands on theDHCPv4 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". |
|
| |
| RFC 7725 | An HTTP Status Code to Report Legal Obstacles |
| |
| Authors: | T. Bray. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7725 |
|
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands. |
|
| |
| RFC 7726 | Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 5884 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7726 |
|
This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional ForwardingDetection) sessions for a given <MPLS LSP, FEC&rt; as described in RFC5884. |
|
| |
| RFC 7727 | Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) |
| |
| Authors: | M. Zhang, H. Wen, J. Hu. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7727 |
|
The Inter-Chassis Communication Protocol (ICCP) supports an inter- chassis redundancy mechanism that is used to support high network availability.
In this document, Provider Edge (PE) devices in a Redundancy Group(RG) running ICCP are used to offer multihomed connectivity toSpanning Tree Protocol (STP) networks to improve availability of theSTP networks. The ICCP TLVs and usage for the ICCP STP application are defined. |
|
| |
| RFC 7728 | RTP Stream Pause and Resume |
| |
| Authors: | B. Burman, A. Akram, R. Even, M. Westerlund. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 5104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7728 |
|
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. |
|
| |
| RFC 7729 | Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management |
| |
| Authors: | B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed.. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7729 |
|
Deployment experience has demonstrated the value of using theForwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, theForwarding Element Manager (FEM) is modeled by creating a LogicalFunctional 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. |
|
| |
| RFC 7730 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | January 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 6490 |
| Obsoleted by: | RFC 8630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7730 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. |
|
| |
| RFC 7731 | Multicast Protocol for Low-Power and Lossy Networks (MPL) |
| |
| Authors: | J. Hui, R. Kelsey. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7731 |
|
This document specifies the Multicast Protocol for Low-Power andLossy 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 MPLForwarders in an MPL Domain.
MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. |
|
| |
| RFC 7732 | Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) |
| |
| Authors: | P. van der Stok, R. Cragie. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7732 |
|
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. |
|
| |
| RFC 7733 | Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control |
| |
| Authors: | A. Brandt, E. Baccelli, R. Cragie, P. van der Stok. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7733 |
|
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power andLossy Networks (RPL) protocol suite to implement the features required for control in building and home environments. |
|
| |
| RFC 7734 | Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) |
| |
| Authors: | D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7734 |
|
This document describes how Ethernet Shortest Path Bridging MAC mode(SPBM) can be combined with Ethernet VPN (EVPN) to interwork withProvider 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 ofEthernet networks. |
|
| |
| RFC 7735 | Tracking Reviews of Documents |
| |
| Authors: | R. Sparks, T. Kivinen. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7735 |
|
Several review teams ensure specific types of review are performed onInternet-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. |
|
| |
| RFC 7736 | Content Delivery Network Interconnection (CDNI) Media Type Registration |
| |
| Authors: | K. Ma. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7736 |
|
This document defines the standard media type used by the ContentDelivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter. |
|
| |
| RFC 7737 | Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification |
| |
| Authors: | N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 7110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7737 |
|
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 thisReply 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 ReplyMode values.
This document updates RFC 7110. |
|
| |
| RFC 7738 | A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) |
| |
| Authors: | M. Blanchet, A. Schiltknecht, P. Shames. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7738 |
|
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). |
|
| |
| RFC 7739 | Security Implications of Predictable Fragment Identification Values |
| |
| Authors: | F. Gont. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7739 |
|
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 IPv6Source 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. |
|
| |
| RFC 7740 | Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication |
| |
| Authors: | Z. Zhang, Y. Rekhter, A. Dolganow. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7740 |
|
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 IngressReplication. This solution enables a service provider to use IngressReplication to offer transparent bidirectional multicast service to its VPN customers. |
|
| |
| RFC 7741 | RTP Payload Format for VP8 Video |
| |
| Authors: | P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7741 |
|
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. |
|
| |
| RFC 7742 | WebRTC Video Processing and Codec Requirements |
| |
| Authors: | A.B. Roach. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7742 |
|
This specification provides the requirements and considerations forWebRTC 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. |
|
| |
| RFC 7743 | Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping |
| |
| Authors: | J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed.. |
| Date: | January 2016 |
| Formats: | txt html json |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7743 |
|
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping andTraceroute"), 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. |
|
| |
| RFC 7744 | Use Cases for Authentication and Authorization in Constrained Environments |
| |
| Authors: | L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7744 |
|
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.
This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.
Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally. |
|
| |
| RFC 7745 | XML Schemas for Reverse DNS Management |
| |
| Authors: | T. Manderson. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7745 |
|
This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational StateTransfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since2011 and is being used by the registries responsible for reverse DNS(rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through anHTTPS transaction that is mediated by an X.509 certificate. |
|
| |
| RFC 7746 | Label Switched Path (LSP) Self-Ping |
| |
| Authors: | R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7746 |
|
When certain RSVP-TE optimizations are implemented, ingress LabelSwitching 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 aRESV 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.
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.
LSP Self-ping is a new protocol. It is not an extension of LSP Ping.Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs. |
|
| |
| RFC 7747 | Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence |
| |
| Authors: | R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7747 |
|
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. |
|
| |
| RFC 7748 | Elliptic Curves for Security |
| |
| Authors: | A. Langley, M. Hamburg, S. Turner. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7748 |
|
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. |
|
| |
| RFC 7749 | The "xml2rfc" Version 2 Vocabulary |
| |
|
|
This document defines the "xml2rfc" version 2 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts.
Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
This document obsoletes RFC 2629. |
|
| |
| RFC 7750 | Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | J. Hedin, G. Mirsky, S. Baillargeon. |
| Date: | February 2016 |
| Formats: | txt json html |
| Updates: | RFC 5357 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7750 |
|
This document describes an optional extension for Two-Way ActiveMeasurement Protocol (TWAMP) allowing the monitoring of theDifferentiated Service Code Point and Explicit CongestionNotification fields with the TWAMP-Test protocol. |
|
| |
| RFC 7751 | 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 MessageAuthentication 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. |
|
| |
| RFC 7752 | North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP |
| |
| Authors: | H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. |
| Date: | March 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9552 |
| Updated by: | RFC 9029 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7752 |
|
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, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs). |
|
| |
| RFC 7753 | Port Control Protocol (PCP) Extension for Port-Set Allocation |
| |
| Authors: | Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7753 |
|
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. |
|
| |
| RFC 7754 | Technical Considerations for Internet Service Blocking and Filtering |
| |
| Authors: | R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7754 |
|
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 theInternet 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. |
|
| |
| RFC 7755 | SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments |
| |
| Authors: | T. Anderson. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7755 |
|
This document describes the use of the Stateless IP/ICMP TranslationAlgorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on theInternet 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.
The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity. |
|
| |
| RFC 7756 | Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode |
| |
| Authors: | T. Anderson, S. Steffann. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7756 |
|
This document describes an extension of the Stateless IP/ICMPTranslation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.
The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755. |
|
| |
| RFC 7757 | Explicit Address Mappings for Stateless IP/ICMP Translation |
| |
| Authors: | T. Anderson, A. Leiva Popper. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7757 |
|
This document extends the Stateless IP/ICMP Translation Algorithm(SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. |
|
| |
| RFC 7758 | Time Capability in NETCONF |
| |
| Authors: | T. Mizrahi, Y. Moses. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7758 |
|
This document defines a capability-based extension to the NetworkConfiguration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allowsNETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. |
|
| |
| RFC 7759 | Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping |
| |
| Authors: | E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7759 |
|
This specification describes the configuration of proactive MPLS-TPOperations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol. |
|
| |
| RFC 7760 | Statement of Work for Extensions to the IETF Datatracker for Author Statistics |
| |
| Authors: | R. Housley. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7760 |
|
This is the Statement of Work (SOW) for extensions to the IETFDatatracker to provide statistics about RFCs and Internet-Drafts and their authors. |
|
| |
| RFC 7761 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.
This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM MulticastBorder Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. |
|
| |
| RFC 7762 | Initial Assignment for the Content Security Policy Directives Registry |
| |
| Authors: | M. West. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7762 |
|
This document establishes an Internet Assigned Number Authority(IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content SecurityPolicy Level 2 specification. |
|
| |
| RFC 7763 | The text/markdown Media Type |
| |
| Authors: | S. Leonard. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7763 |
|
This document registers the text/markdown media type for use withMarkdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. |
|
| |
| RFC 7764 | Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations |
| |
| Authors: | S. Leonard. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7764 |
|
This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.Background information, local storage strategies, and additional syntax registrations are supplied. |
|
| |
| RFC 7765 | TCP and Stream Control Transmission Protocol (SCTP) RTO Restart |
| |
| Authors: | P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7765 |
|
This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited. |
|
| |
| RFC 7766 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.This document obsoletes RFC 5966 and therefore updates RFC 1035 andRFC 1123. |
|
| |
| RFC 7767 | Application-Initiated Check-Pointing via the Port Control Protocol (PCP) |
| |
| Authors: | S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7767 |
|
This document specifies a mechanism for a host to indicate via thePort Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.
This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed. |
|
| |
| RFC 7768 | Port Management to Reduce Logging in Large-Scale NATs |
| |
| Authors: | T. Tsou, W. Li, T. Taylor, J. Huang. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7768 |
|
Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete.There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address.One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs.This document suggests a way to achieve dynamic port sharing while keeping log volumes low. |
|
| |
| RFC 7769 | Media Access Control (MAC) Address Withdrawal over Static Pseudowire |
| |
| Authors: | S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7769 |
|
This document specifies a mechanism to signal Media Access Control(MAC) address withdrawal notification using a pseudowire (PW)Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LANService (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment. |
|
| |
| RFC 7770 | Extensions to OSPF for Advertising Optional Router Capabilities |
| |
| Authors: | A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. |
| Date: | February 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 4970 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7770 |
|
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. The RouterInformation (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an OpaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a uniqueLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities. |
|
| |
| RFC 7771 | Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires |
| |
| Authors: | A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 6870 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7771 |
|
In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection.With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures viaMPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of theSwitching Provider Edge Routers (S-PEs) along the path of the MS-PW.This document describes how to achieve this protection via redundantMS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. |
|
| |
| RFC 7772 | Reducing Energy Consumption of Router Advertisements |
| |
| Authors: | A. Yourtchenko, L. Colitti. |
| Date: | February 2016 |
| Formats: | txt html json |
| Also: | BCP 0202 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7772 |
|
Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. |
|
| |
| RFC 7773 | Authentication Context Certificate Extension |
| |
| Authors: | S. Santesson. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7773 |
|
This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.
This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion MarkupLanguage (SAML) assertion. |
|
| |
| RFC 7774 | Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 |
| |
| Authors: | Y. Doi, M. Gillmore. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7774 |
|
This document defines a way to configure a parameter set for MPL(Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in anMPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters. |
|
| |
| RFC 7775 | IS-IS Route Preference for Extended IP and IPv6 Reachability |
| |
| Authors: | L. Ginsberg, S. Litkowski, S. Previdi. |
| Date: | February 2016 |
| Formats: | txt json html |
| Updates: | RFC 5308 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7775 |
|
In existing specifications, the route preferences for IPv4/IPv6Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2Link State Protocol Data Units (LSPs). This document addresses these issues.
This document updates RFC 5308. |
|
| |
| RFC 7776 | IETF Anti-Harassment Procedures |
| |
|
|
IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.
This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. |
|
| |
| RFC 7777 | Advertising Node Administrative Tags in OSPF |
| |
| Authors: | S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7777 |
|
This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to theOSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.
This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags. |
|
| |
| RFC 7778 | Mobile Communication Congestion Exposure Scenario |
| |
| Authors: | D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7778 |
|
This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPPEvolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. |
|
| |
| RFC 7779 | Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) |
| |
| Authors: | H. Rogge, E. Baccelli. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7779 |
|
This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2). |
|
| |
| RFC 7780 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
Since the publication of the TRILL (Transparent Interconnection ofLots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station AddressDistribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs6325, 7177, and 7179. |
|
| |
| RFC 7781 | Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access |
| |
| Authors: | H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7781 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edgeRBridge (Routing Bridge, or TRILL switch) group providing active- active access to such an end station is represented as a virtualRBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active- active access by such end stations. |
|
| |
| RFC 7782 | Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments |
| |
| Authors: | M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7782 |
|
TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.
This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one hostMedia Access Control (MAC) address being associated with the multipleRBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein. |
|
| |
| RFC 7783 | Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Senevirathne, J. Pathangi, J. Hudson. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7783 |
|
TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of anAppointed Forwarder for a set of VLANs. Appointed Forwarders provideVLAN-based load sharing with an active-standby model. High- performance applications require an active-active load-sharing model.The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtualRBridge (also referred to as a virtual Routing Bridge or virtualTRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF(Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees(CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility toRBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325. |
|
| |
| RFC 7784 | Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB |
| |
| Authors: | D. Kumar, S. Salam, T. Senevirathne. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7784 |
|
This document specifies the MIB for the OAM (Operations,Administration, and Maintenance) objects for IETF TRILL (TransparentInterconnection of Lots of Links). |
|
| |
| RFC 7785 | Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite |
| |
| Authors: | S. Vinapamula, M. Boucadair. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7785 |
|
This document discusses issues induced by the change of the Dual-Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues. |
|
| |
| RFC 7786 | TCP Modifications for Congestion Exposure (ConEx) |
| |
| Authors: | M. Kuehlewind, Ed., R. Scheffenegger. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7786 |
|
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission ControlProtocol (TCP). |
|
| |
| RFC 7787 | Distributed Node Consensus Protocol |
| |
| Authors: | M. Stenberg, S. Barth. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7787 |
|
This document describes the Distributed Node Consensus Protocol(DNCP), a generic state synchronization protocol that uses theTrickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol. |
|
| |
| RFC 7788 | Home Networking Control Protocol |
| |
| Authors: | M. Stenberg, S. Barth, P. Pfister. |
| Date: | April 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8375 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7788 |
|
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address. |
|
| |
| RFC 7789 | Impact of BGP Filtering on Inter-Domain Routing Policies |
| |
| Authors: | C. Cardona, P. Francois, P. Lucente. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7789 |
|
This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes.We provide a review of the techniques to detect the occurrence of this issue and defend against it. |
|
| |
| RFC 7790 | Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) |
| |
| Authors: | Y. Yoneya, T. Nemoto. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7790 |
|
The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both theInternationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers ofPRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters. |
|
| |
| RFC 7791 | Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | D. Migault, Ed., V. Smyslov. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7791 |
|
This document considers a VPN end user establishing an IPsec SecurityAssociation (SA) with a Security Gateway using the Internet KeyExchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.
The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKESA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node. |
|
| |
| RFC 7792 | RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7792 |
|
This memo describes the extensions to the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. |
|
| |
| RFC 7793 | Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry |
| |
|
|
RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."
This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure. |
|
| |
| RFC 7794 | IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability |
| |
| Authors: | L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7794 |
|
This document introduces new sub-TLVs to support advertisement ofIPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement. |
|
| |
| RFC 7795 | Pseudowire Redundancy on the Switching Provider Edge (S-PE) |
| |
| Authors: | J. Dong, H. Wang. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7795 |
|
This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the SwitchingProvider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and6478 is reused. This document does not require any change to theTerminating Provider Edges (T-PEs) of MS-PW. |
|
| |
| RFC 7796 | Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) |
| |
| Authors: | Y. Jiang, Ed., L. Yong, M. Paul. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7796 |
|
This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation. |
|
| |
| RFC 7797 | JSON Web Signature (JWS) Unencoded Payload Option |
| |
|
|
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
This specification updates RFC 7519 by stating that JSON Web Tokens(JWTs) MUST NOT use the unencoded payload option defined by this specification. |
|
| |
| RFC 7798 | RTP Payload Format for High Efficiency Video Coding (HEVC) |
| |
| Authors: | Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7798 |
|
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC InternationalStandard 23008-2, both also known as High Efficiency Video Coding(HEVC) and developed by the Joint Collaborative Team on Video Coding(JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. |
|
| |
| RFC 7799 | Active and Passive Metrics and Methods (with Hybrid Types In-Between) |
| |
| Authors: | A. Morton. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7799 |
|
This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. |
|
