| |
| RFC 6901 | JavaScript Object Notation (JSON) Pointer |
| |
| Authors: | P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6901 |
|
JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. |
|
| |
| RFC 6902 | JavaScript Object Notation (JSON) Patch |
| |
| Authors: | P. Bryan, Ed., M. Nottingham, Ed.. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6902 |
|
JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation(JSON) document; it is suitable for use with the HTTP PATCH method.The "application/json-patch+json" media type is used to identify such patch documents. |
|
| |
| RFC 6903 | Additional Link Relation Types |
| |
| Authors: | J. Snell. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6903 |
|
This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types. |
|
| |
| RFC 6904 | Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) |
| |
|
|
The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-timeTransport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
This document updates RFC 3711, the Secure Real-time TransportProtocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. |
|
| |
| RFC 6905 | Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6905 |
|
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to theTransparent Interconnection of Lots of Links (TRILL). |
|
| |
| RFC 6906 | The 'profile' Link Relation Type |
| |
| Authors: | E. Wilde. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6906 |
|
This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. |
|
| |
| RFC 6907 | Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties |
| |
| Authors: | T. Manderson, K. Sriram, R. White. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6907 |
|
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure(RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system. |
|
| |
| RFC 6908 | Deployment Considerations for Dual-Stack Lite |
| |
| Authors: | Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6908 |
|
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture. |
|
| |
| RFC 6909 | IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6909 |
|
This specification defines a new mobility option, the IPv4 TrafficOffload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session.Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network. |
|
| |
| RFC 6910 | Completion of Calls for the Session Initiation Protocol (SIP) |
| |
| Authors: | D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6910 |
|
The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.
For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session InitiationProtocol Service Examples" (RFC 5359).
For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.
The architecture is designed to interoperate well with existing completion of calls solutions in other networks. |
|
| |
| RFC 6911 | RADIUS Attributes for IPv6 Access Networks |
| |
| Authors: | W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6911 |
|
This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a hostIPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing. |
|
| |
| RFC 6912 | Principles for Unicode Code Point Inclusion in Labels in the DNS |
| |
| Authors: | A. Sullivan, D. Thaler, J. Klensin, O. Kolkman. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6912 |
|
Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points.Most operators of zones should probably not permit registration ofU-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone. |
|
| |
| RFC 6913 | Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) |
| |
| Authors: | D. Hanes, G. Salgueiro, K. Fleming. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6913 |
|
This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP).Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing. |
|
| |
| RFC 6914 | SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6914 |
|
The IETF has produced many specifications related to Presence andInstant Messaging with the Session Initiation Protocol (SIP).Collectively, these specifications are known as SIP for InstantMessaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other. |
|
| |
| RFC 6915 | Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) |
| |
|
|
RFC 6155 specifies an extension for the HTTP-Enabled LocationDelivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.
This document specifies an XML Schema and a URN Sub-Namespace for aFlow Identity Extension for HELD to support this requirement.
This document updates RFC 6155 by deprecating the port number elements specified therein. |
|
| |
| RFC 6916 | Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Gagliano, S. Kent, S. Turner. |
| Date: | April 2013 |
| Formats: | txt html json |
| Also: | BCP 0182 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6916 |
|
This document specifies the process that Certification Authorities(CAs) and Relying Parties (RPs) participating in the Resource PublicKey Infrastructure (RPKI) will need to follow to transition to a new(and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years.Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration(parent migrates before children). |
|
| |
| RFC 6917 | Media Resource Brokering |
| |
| Authors: | C. Boulton, L. Miniero, G. Munson. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6917 |
|
The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol(SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of ApplicationServers and Media Servers. This document introduces a Media ResourceBroker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. |
|
| |
| RFC 6918 | Formally Deprecating Some ICMPv4 Message Types |
| |
|
|
A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletesRFC 1788, and requests the RFC Editor to change the status of RFC1788 to Historic. |
|
| |
| RFC 6919 | Further Key Words for Use in RFCs to Indicate Requirement Levels |
| |
| Authors: | R. Barnes, S. Kent, E. Rescorla. |
| Date: | 1 April 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6919 |
|
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER","REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO","COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919. |
|
| |
| RFC 6920 | Naming Things with Hashes |
| |
| Authors: | S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6920 |
|
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these toHTTP URLs, and binary and human-speakable formats for these names.The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. |
|
| |
| RFC 6921 | Design Considerations for Faster-Than-Light (FTL) Communication |
| |
| Authors: | R. Hinden. |
| Date: | 1 April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6921 |
|
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues. |
|
| |
| RFC 6922 | The application/sql Media Type |
| |
| Authors: | Y. Shafranovich. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6922 |
|
This document registers the application/sql media type to be used for the Structured Query Language (SQL). |
|
| |
| RFC 6923 | MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions |
| |
| Authors: | R. Winter, E. Gray, H. van Helvoort, M. Betts. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6923 |
|
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union TelecommunicationStandardization Sector (ITU-T). |
|
| |
| RFC 6924 | Registration of Second-Level URN Namespaces under "ietf" |
| |
|
|
RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of"ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf". |
|
| |
| RFC 6925 | The DHCPv4 Relay Agent Identifier Sub-Option |
| |
| Authors: | B. Joshi, R. Desetti, M. Stapp. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6925 |
|
This document defines a new Relay Agent Identifier sub-option for theDynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub- option allows a DHCP relay agent to include the identifier in theDHCP messages it sends. |
|
| |
| RFC 6926 | DHCPv4 Bulk Leasequery |
| |
| Authors: | K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. |
| Date: | April 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6926 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. |
|
| |
| RFC 6927 | Variants in Second-Level Names Registered in Top-Level Domains |
| |
| Authors: | J. Levine, P. Hoffman. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6927 |
|
Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS.Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of theIETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA. |
|
| |
| RFC 6928 | Increasing TCP's Initial Window |
| |
| Authors: | J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6928 |
|
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified inRFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. |
|
| |
| RFC 6929 | Remote Authentication Dial In User Service (RADIUS) Protocol Extensions |
| |
|
|
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. |
|
| |
| RFC 6930 | RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) |
| |
| Authors: | D. Guo, S. Jiang, Ed., R. Despres, R. Maglione. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6930 |
|
The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides bothIPv4 and IPv6 connectivity services simultaneously during theIPv4/IPv6 coexistence period. The Dynamic Host ConfigurationProtocol (DHCP) 6rd option has been defined to configure the 6rdCustomer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization andAccounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol.This document defines a Remote Authentication Dial-In User Service(RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. |
|
| |
| RFC 6931 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. |
|
| |
| RFC 6932 | Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry |
| |
| Authors: | D. Harkins, Ed.. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6932 |
|
This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols. |
|
| |
| RFC 6933 | Entity MIB (Version 4) |
| |
| Authors: | A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. |
| Date: | May 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 4133 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6933 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SimpleNetwork Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of theEntity MIB module published as RFC 4133. |
|
| |
| RFC 6934 | Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) |
| |
| Authors: | N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6934 |
|
The purpose of this document is to provide applicability of theAccess Node Control Mechanism to broadband access based on PassiveOptical Networks (PONs). The need for an Access Node ControlMechanism between a Network Access Server (NAS) and an Access NodeComplex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access NodeControl Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node ControlMechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives. |
|
| |
| RFC 6935 | IPv6 and UDP Checksums for Tunneled Packets |
| |
| Authors: | M. Eubanks, P. Chimento, M. Westerlund. |
| Date: | April 2013 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6935 |
|
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing theIPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried.Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method. |
|
| |
| RFC 6936 | Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums |
| |
| Authors: | G. Fairhurst, M. Westerlund. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6936 |
|
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6. |
|
| |
| RFC 6937 | Proportional Rate Reduction for TCP |
| |
| Authors: | M. Mathis, N. Dukkipati, Y. Cheng. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6937 |
|
This document describes an experimental Proportional Rate Reduction(PRR) algorithm as an alternative to the widely deployed FastRecovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm. |
|
| |
| RFC 6938 | Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID |
| |
| Authors: | J. Scudder. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6938 |
|
This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC. |
|
| |
| RFC 6939 | Client Link-Layer Address Option in DHCPv6 |
| |
| Authors: | G. Halwasia, S. Bhandari, W. Dec. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6939 |
|
This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option. |
|
| |
| RFC 6940 | REsource LOcation And Discovery (RELOAD) Base Protocol |
| |
| Authors: | C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6940 |
|
This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. AP2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P SessionInitiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. |
|
| |
| RFC 6941 | MPLS Transport Profile (MPLS-TP) Security Framework |
| |
| Authors: | L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed.. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6941 |
|
This document provides a security framework for the MPLS TransportProfile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context ofMPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and toMPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLSNetworks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionality of a packet transport network. |
|
| |
| RFC 6942 | Diameter Support for the EAP Re-authentication Protocol (ERP) |
| |
| Authors: | J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6942 |
|
The EAP Re-authentication Protocol (ERP) defines extensions to theExtensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifiesDiameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server. |
|
| |
| RFC 6943 | Issues in Identifier Comparison for Security Purposes |
| |
| Authors: | D. Thaler, Ed.. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6943 |
|
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. |
|
| |
| RFC 6944 | Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status |
| |
|
|
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures overDNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. |
|
| |
| RFC 6945 | Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol |
| |
| Authors: | R. Bush, B. Wijnen, K. Patel, M. Baer. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6945 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol. |
|
| |
| RFC 6946 | Processing of IPv6 "Atomic" Fragments |
| |
|
|
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal"fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector. |
|
| |
| RFC 6947 | The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute |
| |
| Authors: | M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6947 |
|
This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative NetworkAddress Types (ANAT) due to their syntax.
The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required,Interactive Connectivity Establishment (ICE), as specified in RFC5245, provides such a solution. |
|
| |
| RFC 6948 | Some Measurements on World IPv6 Day from an End-User Perspective |
| |
| Authors: | A. Keranen, J. Arkko. |
| Date: | July 2013 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6948 |
|
During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services.Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics. |
|
| |
| RFC 6949 | RFC Series Format Requirements and Future Development |
| |
|
|
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223. |
|
| |
| RFC 6950 | Architectural Considerations on Application Features in the DNS |
| |
| Authors: | J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6950 |
|
A number of Internet applications rely on the Domain Name System(DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered. |
|
| |
| RFC 6951 | UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
| |
|
|
This document describes a simple method of encapsulating StreamControl Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacyNATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.
This document covers only end-hosts and not tunneling (egress or ingress) endpoints. |
|
| |
| RFC 6952 | Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide |
| |
| Authors: | M. Jethanandani, K. Patel, L. Zheng. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6952 |
|
This document analyzes TCP-based routing protocols, the BorderGateway Protocol (BGP), the Label Distribution Protocol (LDP), thePath Computation Element Communication Protocol (PCEP), and theMulticast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication forRouting Protocols Design Guidelines", RFC 6518. |
|
| |
| RFC 6953 | Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements |
| |
| Authors: | A. Mancuso, Ed., S. Probasco, B. Patil. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6953 |
|
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. |
|
| |
| RFC 6954 | Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | J. Merkle, M. Lochter. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6954 |
|
This document specifies use of the Elliptic Curve Cryptography (ECC)Brainpool elliptic curve groups for key exchange in the Internet KeyExchange Protocol version 2 (IKEv2). |
|
| |
| RFC 6955 | Diffie-Hellman Proof-of-Possession Algorithms |
| |
| Authors: | J. Schaad, H. Prafullchandra. |
| Date: | May 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 2875 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6955 |
|
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
This document obsoletes RFC 2875. |
|
| |
| RFC 6956 | Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library |
| |
| Authors: | W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6956 |
|
This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES ForwardingElement (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. |
|
| |
| RFC 6957 | Duplicate Address Detection Proxy |
| |
| Authors: | F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6957 |
|
The document describes a proxy-based mechanism allowing the use ofDuplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address. |
|
| |
| RFC 6958 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting |
| |
| Authors: | A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6958 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications. |
|
| |
| RFC 6959 | Source Address Validation Improvement (SAVI) Threat Scope |
| |
| Authors: | D. McPherson, F. Baker, J. Halpern. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6959 |
|
The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. |
|
| |
| RFC 6960 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
|
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CertificateRevocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. |
|
| |
| RFC 6961 | The Transport Layer Security (TLS) Multiple Certificate Status Request Extension |
| |
|
|
This document defines the Transport Layer Security (TLS) CertificateStatus Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the CertificateStatus extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate StatusProtocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain. |
|
| |
| RFC 6962 | Certificate Transparency |
| |
| Authors: | B. Laurie, A. Langley, E. Kasper. |
| Date: | June 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9162 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6962 |
|
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcingCAs to add all issued certificates to the logs.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. |
|
| |
| RFC 6963 | A Uniform Resource Name (URN) Namespace for Examples |
| |
|
|
This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation. |
|
| |
| RFC 6964 | Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6964 |
|
Many end-user sites in the Internet today still have predominantlyIPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using theIntra-Site Automatic Tunnel Addressing Protocol (ISATAP). |
|
| |
| RFC 6965 | MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design |
| |
| Authors: | L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6965 |
|
This document describes the applicability of the MPLS TransportProfile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport. |
|
| |
| RFC 6967 | Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments |
| |
| Authors: | M. Boucadair, J. Touch, P. Levis, R. Penno. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6967 |
|
This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.
This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches. |
|
| |
| RFC 6968 | FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca, B. Adamson. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6968 |
|
This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered CodingTransport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol. |
|
| |
| RFC 6969 | OSPFv3 Instance ID Registry Update |
| |
|
|
This document modifies the "Unassigned" number space in the IANA"OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838. |
|
| |
| RFC 6970 | Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6970 |
|
This document specifies the behavior of the Universal Plug and Play(UPnP) Internet Gateway Device - Port Control Protocol InterworkingFunction (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparentNAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router. |
|
| |
| RFC 6971 | Depth-First Forwarding (DFF) in Unreliable Networks |
| |
| Authors: | U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes. |
| Date: | June 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6971 |
|
This document specifies the Depth-First Forwarding (DFF) protocol forIPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies theDFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only. |
|
| |
| RFC 6972 | Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) |
| |
| Authors: | Y. Zhang, N. Zong. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6972 |
|
Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols.This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer StreamingProtocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP. |
|
| |
| RFC 6973 | Privacy Considerations for Internet Protocols |
| |
| Authors: | A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6973 |
|
This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy- related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. |
|
| |
| RFC 6974 | Applicability of MPLS Transport Profile for Ring Topologies |
| |
| Authors: | Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6974 |
|
This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile(MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in"Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLSTransport Profile (MPLS-TP) Survivability Framework" (RFC 6372).This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology. |
|
| |
| RFC 6975 | Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) |
| |
| Authors: | S. Crocker, S. Rose. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6975 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in aDNSSEC-signed zone. |
|
| |
| RFC 6976 | Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach |
| |
| Authors: | M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6976 |
|
This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.
This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes.It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.
After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.
The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
|
| |
| RFC 6977 | Triggering DHCPv6 Reconfiguration from Relay Agents |
| |
| Authors: | M. Boucadair, X. Pougnard. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6977 |
|
This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by aDHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message. |
|
| |
| RFC 6978 | A TCP Authentication Option Extension for NAT Traversal |
| |
| Authors: | J. Touch. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6978 |
|
This document describes an extension to the TCP Authentication Option(TCP-AO) to support its use over connections that pass throughNetwork Address Translators and/or Network Address and PortTranslators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms. |
|
| |
| RFC 6979 | Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) |
| |
| Authors: | T. Pornin. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6979 |
|
This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard DigitalSignature Algorithm (DSA) and Elliptic Curve Digital SignatureAlgorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. |
|
| |
| RFC 6980 | Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery |
| |
|
|
This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated. |
|
| |
| RFC 6981 | A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses |
| |
| Authors: | S. Bryant, S. Previdi, M. Shand. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6981 |
|
This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification.The document represents a snapshot of the work of the Routing AreaWorking Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
|
| |
| RFC 6982 | Improving Awareness of Running Code: The Implementation Status Section |
| |
|
|
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
The process in this document is offered as an experiment. Authors ofInternet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. |
|
| |
| RFC 6983 | Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) |
| |
| Authors: | R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6983 |
|
This document presents thoughts on the potential impact of supportingHTTP Adaptive Streaming (HAS) technologies in Content DistributionNetwork Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI.This document has been used as input information during the CDNI working group process for making a decision regarding support forHAS. |
|
| |
| RFC 6984 | Interoperability Report for Forwarding and Control Element Separation (ForCES) |
| |
| Authors: | W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim. |
| Date: | August 2013 |
| Formats: | txt html json |
| Updates: | RFC 6053 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6984 |
|
This document captures the results of the second Forwarding andControl Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the firstForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results. |
|
| |
| RFC 6985 | IMIX Genome: Specification of Variable Packet Sizes for Additional Testing |
| |
| Authors: | A. Morton. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6985 |
|
Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX"("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification. |
|
| |
| RFC 6986 | GOST R 34.11-2012: Hash Function |
| |
| Authors: | V. Dolmatov, Ed., A. Degtyarev. |
| Date: | August 2013 |
| Formats: | txt json html |
| Updates: | RFC 5831 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6986 |
|
This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831. |
|
| |
| RFC 6987 | OSPF Stub Router Advertisement |
| |
| Authors: | A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. |
| Date: | September 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 3137 |
| Updated by: | RFC 8770 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6987 |
|
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.
This document obsoletes RFC 3137. |
|
| |
| RFC 6988 | Requirements for Energy Management |
| |
| Authors: | J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6988 |
|
This document defines requirements for standards specifications forEnergy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions.Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, PowerInlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.
This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management. |
|
| |
| RFC 6989 | Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2(IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996. |
|
| |
| RFC 6990 | RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting |
| |
| Authors: | R. Huang, Q. Wu, H. Asaeda, G. Zorn. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6990 |
|
An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP.The metrics specified in the RTCP XR block are not dependent onProgram Specific Information (PSI) carried in MPEG-2 TS. |
|
| |
| RFC 6991 | Common YANG Data Types |
| |
|
|
This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC6021. |
|
| |
| RFC 6992 | Routing for IPv4-Embedded IPv6 Packets |
| |
| Authors: | D. Cheng, M. Boucadair, A. Retana. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6992 |
|
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described inRFCs 6145 and 6052, along with a separate OSPFv3 routing table forIPv4-embedded IPv6 routes in the IPv6 network. |
|
| |
| RFC 6993 | Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6993 |
|
This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session InitiationProtocol (SIP). |
|
| |
| RFC 6994 | Shared Use of Experimental TCP Options |
| |
| Authors: | J. Touch. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6994 |
|
This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. |
|
| |
| RFC 6996 | Autonomous System (AS) Reservation for Private Use |
| |
|
|
This document describes the reservation of Autonomous System Numbers(ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. |
|
| |
| RFC 6997 | Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks |
| |
| Authors: | M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6997 |
|
This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and LossyNetworks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints. |
|
| |
| RFC 6998 | A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network |
| |
| Authors: | M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6998 |
|
This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route. |
|
