Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 7700 - 7799s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
 
Authors:P. Saint-Andre.
Date:December 2015
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7700
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:W. George, S. Amante.
Date:November 2015
Formats:txt pdf
Updates:RFC 4271
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7705
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 pdf
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
 
Authors:F. Gont, T. Chown.
Date:March 2016
Formats:txt pdf
Obsoletes:RFC 5157
Status:INFORMATIONAL
DOI:10.17487/RFC 7707
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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)
 
Authors:K. Pentikousis, Ed., E. Zhang, Y. Cui.
Date:December 2015
Formats:txt pdf
Updates:RFC 4656, RFC 5357
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7717
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)
 
Authors:A. Morton.
Date:December 2015
Formats:txt pdf
Updates:RFC 4656
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7718
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 pdf
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
 
Authors:M. Blanchet, L-J. Liman.
Date:December 2015
Formats:txt pdf
Obsoletes:RFC 2870
Also:BCP 0040
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7720
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 pdf
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)
 
Authors:C. Dearlove, T. Clausen.
Date:December 2015
Formats:txt pdf
Updates:RFC 7188, RFC 7631
Status:EXPERIMENTAL
DOI:10.17487/RFC 7722
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
Obsoletes:RFC 6490
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Reschke.
Date:February 2016
Formats:txt pdf
Obsoletes:RFC 2629
Obsoleted by:RFC 7991
Status:INFORMATIONAL
DOI:10.17487/RFC 7749
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 pdf
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)
 
Authors:S. Sorce, T. Yu.
Date:March 2016
Formats:txt pdf
Updates:RFC 4120
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7751
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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)
 
Authors:B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng.
Date:March 2016
Formats:txt pdf
Obsoletes:RFC 4601
Also:STD 0083
Status:INTERNET STANDARD
DOI:10.17487/RFC 7761
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, D. Wessels.
Date:March 2016
Formats:txt pdf
Obsoletes:RFC 5966
Updates:RFC 1035, RFC 1123
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7766
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:P. Resnick, A. Farrel.
Date:March 2016
Formats:txt pdf
Updates:RFC 2418, RFC 7437
Also:BCP 0025
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7776
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 pdf
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 pdf
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 pdf
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
 
Authors:D. Eastlake 3rd, M. Zhang, R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta.
Date:February 2016
Formats:txt pdf
Obsoletes:RFC 7180
Updates:RFC 6325, RFC 7177, RFC 7179
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7780
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:M. Andrews.
Date:May 2016
Formats:txt pdf
Also:BCP 0163
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7793
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 pdf
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 pdf
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 pdf
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
 
Authors:M. Jones.
Date:February 2016
Formats:txt pdf
Updates:RFC 7519
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7797
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 pdf
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 pdf
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.