| |
| RFC 7001 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7002 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting |
| |
| Authors: | A. Clark, G. Zorn, Q. Wu. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7002 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications. |
|
| |
| RFC 7003 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting |
| |
| Authors: | A. Clark, R. Huang, Q. Wu, Ed.. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7003 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications. |
|
| |
| RFC 7004 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting |
| |
| Authors: | G. Zorn, R. Schott, Q. Wu, Ed., R. Huang. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7004 |
|
This document defines three RTP Control Protocol (RTCP) ExtendedReport (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications. |
|
| |
| RFC 7005 | RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting |
| |
| Authors: | A. Clark, V. Singh, Q. Wu. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7005 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications. |
|
| |
| RFC 7006 | Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) |
| |
| Authors: | M. Garcia-Martin, S. Veikkolainen, R. Gilman. |
| Date: | September 2013 |
| Formats: | txt pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7006 |
|
The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities.This negotiation is embedded into the widely used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth("b=" line), connection data ("c=" line), and session or media titles("i=" line for each session or media). |
|
| |
| RFC 7007 | Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) |
| |
|
|
The RTP Profile for Audio and Video Conferences with Minimal Control(RTP/AVP) is the basis for many other profiles, such as the SecureReal-time Transport Protocol (RTP/SAVP), the Extended RTP Profile forReal-time Transport Control Protocol (RTCP)-Based Feedback(RTP/AVPF), and the Extended Secure RTP Profile for RTCP-BasedFeedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published. |
|
| |
| RFC 7008 | A Description of the KCipher-2 Encryption Algorithm |
| |
| Authors: | S. Kiyomoto, W. Shin. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7008 |
|
This document describes the KCipher-2 encryption algorithm.KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. |
|
| |
| RFC 7009 | OAuth 2.0 Token Revocation |
| |
| Authors: | T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7009 |
|
This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed.This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. |
|
| |
| RFC 7010 | IPv6 Site Renumbering Gap Analysis |
| |
| Authors: | B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7010 |
|
This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process. |
|
| |
| RFC 7011 | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information |
| |
|
|
This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. This document obsoletes RFC 5101. |
|
| |
| RFC 7012 | Information Model for IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Claise, Ed., B. Trammell, Ed.. |
| Date: | September 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 5102 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7012 |
|
This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIXInformation Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic MeteringProcess, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. |
|
| |
| RFC 7013 | Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements |
| |
| Authors: | B. Trammell, B. Claise. |
| Date: | September 2013 |
| Formats: | txt html json |
| Also: | BCP 0184 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7013 |
|
This document provides guidelines for how to write definitions of newInformation Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIXInformation Element registry, and provides guidelines for expert reviewers to evaluate new registrations. |
|
| |
| RFC 7014 | Flow Selection Techniques |
| |
| Authors: | S. D'Antonio, T. Zseby, C. Henke, L. Peluso. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7014 |
|
The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate FlowSelection Process may be located at an IP Flow Information Export(IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring FlowRecords. This document describes motivations for using theIntermediate Flow Selection process and presents Intermediate FlowSelection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow SelectionProcess should be exported. |
|
| |
| RFC 7015 | Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol |
| |
| Authors: | B. Trammell, A. Wagner, B. Claise. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7015 |
|
This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export(IPFIX) protocol to the handling of Aggregated Flows, which are IPFIXFlows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. |
|
| |
| RFC 7016 | Adobe's Secure Real-Time Media Flow Protocol |
| |
| Authors: | M. Thornburgh. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7016 |
|
This memo describes Adobe's Secure Real-Time Media Flow Protocol(RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client- server communications, even when Network Address Translators (NATs) are used. |
|
| |
| RFC 7017 | IMAP Access to IETF Email List Archives |
| |
| Authors: | R. Sparks. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7017 |
|
The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists.Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service. |
|
| |
| RFC 7018 | Auto-Discovery VPN Problem Statement and Requirements |
| |
| Authors: | V. Manral, S. Hanna. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7018 |
|
This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.
Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements. |
|
| |
| RFC 7019 | Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Buford, M. Kolberg, Ed.. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7019 |
|
We define a REsource LOcation And Discovery (RELOAD) Usage forApplication-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay- independent way. Two example algorithms are defined, based on Scribe and P2PCast.
This document is a product of the Scalable Adaptive MulticastResearch Group (SAM RG). |
|
| |
| RFC 7020 | The Internet Numbers Registry System |
| |
| Authors: | R. Housley, J. Curran, G. Huston, D. Conrad. |
| Date: | August 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 2050 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7020 |
|
This document provides information about the current Internet NumbersRegistry System used in the distribution of globally unique InternetProtocol (IP) address space and autonomous system (AS) numbers.
This document also provides information about the processes for further evolution of the Internet Numbers Registry System.
This document replaces RFC 2050.
This document does not propose any changes to the current InternetNumbers Registry System. Rather, it documents the Internet NumbersRegistry System as it works today. |
|
| |
| RFC 7021 | Assessing the Impact of Carrier-Grade NAT on Network Applications |
| |
| Authors: | C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7021 |
|
NAT444 is an IPv4 extension technology being considered by ServiceProviders as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier-Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for commonInternet applications. This document was updated to include theDual-Stack Lite (DS-Lite) impacts also. |
|
| |
| RFC 7022 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
| Authors: | A. Begen, C. Perkins, D. Wing, E. Rescorla. |
| Date: | September 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 6222 |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7022 |
|
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.
For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCPCNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC6222. |
|
| |
| RFC 7023 | MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking |
| |
| Authors: | D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7023 |
|
This document specifies the mapping of defect states between EthernetAttachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge(PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. |
|
| |
| RFC 7024 | Virtual Hub-and-Spoke in BGP/MPLS VPNs |
| |
| Authors: | H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7024 |
|
With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each ProviderEdge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers. |
|
| |
| RFC 7025 | Requirements for GMPLS Applications of PCE |
| |
| Authors: | T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7025 |
|
The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE. |
|
| |
| RFC 7026 | Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel |
| |
| Authors: | A. Farrel, S. Bryant. |
| Date: | September 2013 |
| Formats: | txt html json |
| Updates: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7026 |
|
The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header(ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are calledACH TLVs
No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.
This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. |
|
| |
| RFC 7027 | Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) |
| |
|
|
This document specifies the use of several Elliptic CurveCryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. |
|
| |
| RFC 7028 | Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 |
| |
| Authors: | JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7028 |
|
This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile AccessGateway can provide access to multicast content in the local network.The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting differentPMIPv6 deployment scenarios. |
|
| |
| RFC 7029 | Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding |
| |
| Authors: | S. Hartman, M. Wasserman, D. Zhang. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7029 |
|
As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC3748 that protects tunnel methods against man-in-the-middle attacks.However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations. |
|
| |
| RFC 7030 | Enrollment over Secure Transport |
| |
|
|
This document profiles certificate enrollment for clients usingCertificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport(EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority(CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. |
|
| |
| RFC 7031 | DHCPv6 Failover Requirements |
| |
| Authors: | T. Mrugalski, K. Kinnear. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7031 |
|
The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. |
|
| |
| RFC 7032 | LDP Downstream-on-Demand in Seamless MPLS |
| |
| Authors: | T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7032 |
|
Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDPDownstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.
In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. |
|
| |
| RFC 7033 | WebFinger |
| |
| Authors: | P. Jones, G. Salgueiro, M. Jones, J. Smarr. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7033 |
|
This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on theInternet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. |
|
| |
| RFC 7034 | HTTP Header Field X-Frame-Options |
| |
| Authors: | D. Ross, T. Gondrom. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7034 |
|
To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages. |
|
| |
| RFC 7035 | Relative Location Representation |
| |
| Authors: | M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7035 |
|
This document defines an extension to the Presence Information DataFormat Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point.The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.
Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset. |
|
| |
| RFC 7036 | Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group |
| |
| Authors: | R. Housley. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7036 |
|
When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7037 | RADIUS Option for the DHCPv6 Relay Agent |
| |
| Authors: | L. Yeh, M. Boucadair. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7037 |
|
The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the NetworkAccess Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. TheDHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests. |
|
| |
| RFC 7038 | Use of OSPF-MDR in Single-Hop Broadcast Networks |
| |
|
|
RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks(MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANETDesignated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. |
|
| |
| RFC 7039 | Source Address Validation Improvement (SAVI) Framework |
| |
| Authors: | J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7039 |
|
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. |
|
| |
| RFC 7040 | Public IPv4-over-IPv6 Access Network |
| |
| Authors: | Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7040 |
|
This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows theHub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public4over6 aims to provide uninterrupted IPv4 services to users, likeInternet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network. |
|
| |
| RFC 7041 | Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging |
| |
| Authors: | F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7041 |
|
The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multipleProvider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipointVLAN tunnels. PBB can be used to attain better scalability thanProvider Bridges (PBs) in terms of the number of customer MediaAccess Control addresses and the number of service instances that can be supported.
The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid SpanningTree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.
This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model. |
|
| |
| RFC 7042 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. |
|
| |
| RFC 7043 | Resource Records for EUI-48 and EUI-64 Addresses in the DNS |
| |
| Authors: | J. Abley. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7043 |
|
48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended UniqueIdentifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.
This document describes two new DNS resource record types, EUI48 andEUI64, for encoding Ethernet addresses in the DNS.
This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated. |
|
| |
| RFC 7044 | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
| Authors: | M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg. |
| Date: | February 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4244 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7044 |
|
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field.This document obsoletes RFC 4244. |
|
| |
| RFC 7045 | Transmission and Processing of IPv6 Extension Headers |
| |
|
|
Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. |
|
| |
| RFC 7046 | A Common API for Transparent Hybrid Multicast |
| |
| Authors: | M. Waehlisch, T. Schmidt, S. Venaas. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7046 |
|
Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current MulticastDomains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM)Research Group. |
|
| |
| RFC 7047 | The Open vSwitch Database Management Protocol |
| |
| Authors: | B. Pfaff, B. Davie, Ed.. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7047 |
|
Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations. |
|
| |
| RFC 7048 | Neighbor Unreachability Detection Is Too Impatient |
| |
| Authors: | E. Nordmark, I. Gashinsky. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7048 |
|
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.That function is very useful when a host has an alternative neighbor-- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC4861. |
|
| |
| RFC 7049 | Concise Binary Object Representation (CBOR) |
| |
| Authors: | C. Bormann, P. Hoffman. |
| Date: | October 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7049 |
|
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. |
|
| |
| RFC 7050 | Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis |
| |
| Authors: | T. Savolainen, J. Korhonen, D. Wing. |
| Date: | November 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7050 |
|
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-knownIPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. |
|
| |
| RFC 7051 | Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix |
| |
| Authors: | J. Korhonen, Ed., T. Savolainen, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7051 |
|
Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by theNAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery. |
|
| |
| RFC 7052 | Locator/ID Separation Protocol (LISP) MIB |
| |
| Authors: | G. Schudel, A. Jain, V. Moreno. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7052 |
|
This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol(LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information,LISP functional status, and operational counters and other statistics. |
|
| |
| RFC 7053 | SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol |
| |
|
|
This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SelectiveAcknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. |
|
| |
| RFC 7054 | Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) |
| |
| Authors: | A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7054 |
|
The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how theMaintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.
This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine.Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. |
|
| |
| RFC 7055 | A GSS-API Mechanism for the Extensible Authentication Protocol |
| |
| Authors: | S. Hartman, Ed., J. Howlett. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7055 |
|
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the ExtensibleAuthentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define howSimple Authentication and Security Layer (SASL) applications use theExtensible Authentication Protocol. |
|
| |
| RFC 7056 | Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism |
| |
| Authors: | S. Hartman, J. Howlett. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7056 |
|
The naming extensions to the Generic Security Service ApplicationProgramming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting(AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to processSecurity Assertion Markup Language (SAML) messages provided in theAAA response. This document describes how to use the NamingExtensions API to access that information. |
|
| |
| RFC 7057 | Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) |
| |
| Authors: | S. Winter, J. Salowey. |
| Date: | December 2013 |
| Formats: | txt json html |
| Updates: | RFC 3748 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7057 |
|
This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of theEAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. |
|
| |
| RFC 7058 | Media Control Channel Framework (CFW) Call Flow Examples |
| |
| Authors: | A. Amirante, T. Castaldi, L. Miniero, S P. Romano. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7058 |
|
This document provides a list of typical Media Control ChannelFramework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based MediaServers, as well as a base reference document for both implementors and protocol researchers. |
|
| |
| RFC 7059 | A Comparison of IPv6-over-IPv4 Tunnel Mechanisms |
| |
| Authors: | S. Steffann, I. van Beijnum, R. van Rein. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7059 |
|
This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them. |
|
| |
| RFC 7060 | Using LDP Multipoint Extensions on Targeted LDP Sessions |
| |
| Authors: | M. Napierala, E. Rosen, IJ. Wijnands. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7060 |
|
Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label SwitchedPaths. However, the specification for the Multipoint Extensions toLDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over aTargeted LDP session. |
|
| |
| RFC 7061 | eXtensible Access Control Markup Language (XACML) XML Media Type |
| |
| Authors: | R. Sinnema, E. Wilde. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7061 |
|
This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). |
|
| |
| RFC 7062 | Framework for GMPLS and PCE Control of G.709 Optical Transport Networks |
| |
| Authors: | F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7062 |
|
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol LabelSwitching (GMPLS) and Path Computation Element (PCE) control ofOptical Transport Networks (OTNs) as specified in ITU-TRecommendation G.709 as published in 2012. |
|
| |
| RFC 7063 | Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments |
| |
| Authors: | L. Zheng, J. Zhang, R. Parekh. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7063 |
|
This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard. |
|
| |
| RFC 7064 | URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol |
| |
| Authors: | S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7064 |
|
This document specifies the syntax and semantics of the UniformResource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. |
|
| |
| RFC 7065 | Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers |
| |
| Authors: | M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7065 |
|
This document specifies the syntax of Uniform Resource Identifier(URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURNResolution Mechanism (RFC 5928). |
|
| |
| RFC 7066 | IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts |
| |
| Authors: | J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. |
| Date: | November 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 3316 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7066 |
|
As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), UniversalMobile Telecommunications System (UMTS), or Evolved Packet System(EPS) networks (hereafter collectively referred to as ThirdGeneration Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. |
|
| |
| RFC 7067 | Directory Assistance Problem and High-Level Design Proposal |
| |
| Authors: | L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7067 |
|
Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station AddressDistribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame'sData Label across the TRILL campus.
This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (AddressResolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security. |
|
| |
| RFC 7068 | Diameter Overload Control Requirements |
| |
| Authors: | E. McMurry, B. Campbell. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7068 |
|
When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. |
|
| |
| RFC 7069 | DECoupled Application Data Enroute (DECADE) |
| |
| Authors: | R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7069 |
|
Content distribution applications, such as those employing peer-to- peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end- host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples. |
|
| |
| RFC 7070 | An Architecture for Reputation Reporting |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7070 |
|
This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over theInternet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model. |
|
| |
| RFC 7071 | A Media Type for Reputation Interchange |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7071 |
|
This document defines the format of reputation response data("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets. |
|
| |
| RFC 7072 | A Reputation Query Protocol |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7072 |
|
This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) usingJavaScript Object Notation (JSON) as the payload meta-format. |
|
| |
| RFC 7073 | A Reputation Response Set for Email Identifiers |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7073 |
|
This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons. |
|
| |
| RFC 7074 | Revised Definition of the GMPLS Switching Capability and Type Fields |
| |
|
|
GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via theSwitching Capability field, and in signaling protocols via theSwitching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of theSwitching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs3471, 4202, 4203, and 5307. |
|
| |
| RFC 7075 | Realm-Based Redirection In Diameter |
| |
| Authors: | T. Tsou, R. Hao, T. Taylor, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Updates: | RFC 6733 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7075 |
|
The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when theStraightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".
This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-TimeAttribute-Value Pairs (AVPs). |
|
| |
| RFC 7076 | P6R's Secure Shell Public Key Subsystem |
| |
| Authors: | M. Joseph, J. Susoy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7076 |
|
The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.
The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key ManagementInteroperability Protocol (KMIP), Simple Network Management Protocol(SNMP)).
The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).
Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819. |
|
| |
| RFC 7077 | Update Notifications for Proxy Mobile IPv6 |
| |
| Authors: | S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7077 |
|
This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. |
|
| |
| RFC 7078 | Distributing Address Selection Policy Using DHCPv6 |
| |
| Authors: | A. Matsumoto, T. Fujisaki, T. Chown. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7078 |
|
RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site. |
|
| |
| RFC 7079 | The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results |
| |
| Authors: | N. Del Regno, Ed., A. Malis, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7079 |
|
The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual CircuitConnectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word. |
|
| |
| RFC 7080 | Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges |
| |
| Authors: | A. Sajassi, S. Salam, N. Bitar, F. Balus. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7080 |
|
The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE802.1ah-2008. It aims to improve the scalability of Media AccessControl (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used inH-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. |
|
| |
| RFC 7081 | CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | E. Ivov, P. Saint-Andre, E. Marocco. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7081 |
|
This document suggests some strategies for the combined use of theSession Initiation Protocol (SIP) and the Extensible Messaging andPresence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real- time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication. |
|
| |
| RFC 7082 | Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) |
| |
| Authors: | R. Shekh-Yusef, M. Barnes. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7082 |
|
The Centralized Conferencing Manipulation Protocol (CCMP) document(RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for theCentralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.
This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the<service-uris&rt; element in the SIP conferencing event package. |
|
| |
| RFC 7083 | Modification to Default Values of SOL_MAX_RT and INF_MAX_RT |
| |
|
|
This document updates RFC 3315 by redefining the default values forSOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT andINF_MAX_RT with new values. |
|
| |
| RFC 7084 | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 RapidDeployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-StackLite (DS-Lite) are covered in the document. The document obsoletesRFC 6204. |
|
| |
| RFC 7085 | Top-Level Domains That Are Already Dotless |
| |
| Authors: | J. Levine, P. Hoffman. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7085 |
|
Recent statements from the Internet Architecture Board (IAB) and theInternet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others. |
|
| |
| RFC 7086 | Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | A. Keranen, G. Camarillo, J. Maenpaa. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7086 |
|
This document is the HIP-Based Overlay Networking Environment (HIPBONE) instance specification for the REsource LOcation And Discovery(RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. |
|
| |
| RFC 7087 | A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations |
| |
| Authors: | H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed.. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7087 |
|
The MPLS Transport Profile (MPLS-TP) is based on a profile of theMPLS and Pseudowire (PW) procedures as specified in the MPLS TrafficEngineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force(IETF). The International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) has specified a Transport Network architecture.
This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport NetworkRecommendations.
It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations ofMPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. |
|
| |
| RFC 7088 | Session Initiation Protocol Service Example -- Music on Hold |
| |
| Authors: | D. Worley. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7088 |
|
"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards- compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music- on-hold method described in Section 2.3 of RFC 5359. |
|
| |
| RFC 7089 | HTTP Framework for Time-Based Access to Resource States -- Memento |
| |
| Authors: | H. Van de Sompel, M. Nelson, R. Sanderson. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7089 |
|
The HTTP-based Memento framework bridges the present and past Web.It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource. |
|
| |
| RFC 7090 | Public Safety Answering Point (PSAP) Callback |
| |
| Authors: | H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7090 |
|
After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim.A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.
The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to markPSAP callbacks. |
|
| |
| RFC 7091 | GOST R 34.10-2012: Digital Signature Algorithm |
| |
| Authors: | V. Dolmatov, Ed., A. Degtyarev. |
| Date: | December 2013 |
| Formats: | txt html json |
| Updates: | RFC 5832 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7091 |
|
This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of theRussian cryptographic standard algorithms (called GOST algorithms).Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832. |
|
| |
| RFC 7092 | A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents |
| |
| Authors: | H. Kaplan, V. Pascual. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7092 |
|
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server(UAS) and User Agent Client (UAC).
There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs),Session Border Controllers (SBCs), and Application Servers (ASs).This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference. |
|
| |
| RFC 7093 | Additional Methods for Generating Key Identifiers Values |
| |
| Authors: | S. Turner, S. Kent, J. Manger. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7093 |
|
This document specifies additional example methods for generating KeyIdentifier values for use in the AKI (Authority Key Identifier) andSKI (Subject Key Identifier) certificate extensions. |
|
| |
| RFC 7094 | Architectural Considerations of IP Anycast |
| |
| Authors: | D. McPherson, D. Oran, D. Thaler, E. Osterweil. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7094 |
|
This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. |
|
| |
| RFC 7095 | jCard: The JSON Format for vCard |
| |
| Authors: | P. Kewisch. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7095 |
|
This specification defines "jCard", a JSON format for vCard data.The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. |
|
| |
| RFC 7096 | Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) |
| |
| Authors: | S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7096 |
|
ITU-T recommendation G.709-2012 has introduced new fixed and flexibleOptical channel Data Unit (ODU) containers in Optical TransportNetworks (OTNs).
This document provides an evaluation of existing GeneralizedMultiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs. |
|
| |
| RFC 7097 | RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets |
| |
| Authors: | J. Ott, V. Singh, Ed., I. Curcio. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7097 |
|
The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception. |
|
| |
| RFC 7098 | Using the IPv6 Flow Label for Load Balancing in Server Farms |
| |
| Authors: | B. Carpenter, S. Jiang, W. Tarreau. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7098 |
|
This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms. |
|
