| |
| RFC 6201 | Device Reset Characterization |
| |
|
|
An operational forwarding device may need to be restarted(automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. |
|
| |
| RFC 6202 | Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP |
| |
| Authors: | S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6202 |
|
On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. |
|
| |
| RFC 6203 | IMAP4 Extension for Fuzzy Search |
| |
| Authors: | T. Sirainen. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6203 |
|
This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. |
|
| |
| RFC 6204 | Basic Requirements for IPv6 Customer Edge Routers |
| |
| Authors: | H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7084 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6204 |
|
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. |
|
| |
| RFC 6205 | Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers |
| |
|
|
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.Global wavelength semantics are not considered.
In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the DenseWavelength Division Multiplexing (DWDM) and Coarse WavelengthDivision Multiplexing (CWDM) grids defined by the InternationalTelecommunication Union Telecommunication Standardization Sector.The label format defined in this document can be used in GMPLS signaling and routing protocols. |
|
| |
| RFC 6206 | The Trickle Algorithm |
| |
| Authors: | P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6206 |
|
The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. |
|
| |
| RFC 6207 | The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml |
| |
| Authors: | R. Denenberg, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6207 |
|
This document specifies media types for the following formats: MODS(Metadata Object Description Schema), MADS (Metadata AuthorityDescription Schema), METS (Metadata Encoding and TransmissionStandard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are allXML schemas providing representations of various forms of information including metadata and search results. |
|
| |
| RFC 6208 | Cloud Data Management Interface (CDMI) Media Types |
| |
| Authors: | K. Sankar, Ed., A. Jones. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6208 |
|
This document describes several Internet media types defined for theCloud Data Management Interface (CDMI) by the Storage NetworkingIndustry Association (SNIA). The media types are: o application/cdmi-object o application/cdmi-container o application/cdmi-domain o application/cdmi-capability o application/cdmi-queue |
|
| |
| RFC 6209 | Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) |
| |
| Authors: | W. Kim, J. Lee, J. Park, D. Kwon. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6209 |
|
This document specifies a set of cipher suites for the TransportLayer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. |
|
| |
| RFC 6210 | Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME |
| |
| Authors: | J. Schaad. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6210 |
|
New hash algorithms are being developed that may include parameters.Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. |
|
| |
| RFC 6211 | Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute |
| |
| Authors: | J. Schaad. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6211 |
|
The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. |
|
| |
| RFC 6212 | Authentication-Results Registration for Vouch by Reference Results |
| |
| Authors: | M. Kucherawy. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6212 |
|
This memo updates the registry of properties in Authentication-Results: message header fields to allow relaying of the results of aVouch By Reference query. |
|
| |
| RFC 6213 | IS-IS BFD-Enabled TLV |
| |
| Authors: | C. Hopps, L. Ginsberg. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6213 |
|
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of theBidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to aBFD-detected forwarding plane failure without use of either this TLV or some other method. |
|
| |
| RFC 6214 | Adaptation of RFC 1149 for IPv6 |
| |
|
|
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. |
|
| |
| RFC 6215 | MPLS Transport Profile User-to-Network and Network-to-Network Interfaces |
| |
| Authors: | M. Bocci, L. Levrau, D. Frost. |
| Date: | April 2011 |
| Formats: | txt json html |
| Updates: | RFC 5921 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6215 |
|
The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) TransportService Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.
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 functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6216 | Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms |
| |
| Authors: | C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6216 |
|
This document shows example call flows demonstrating the use ofTransport Layer Security (TLS), and Secure/Multipurpose Internet MailExtensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. |
|
| |
| RFC 6217 | Regional Broadcast Using an Atmospheric Link Layer |
| |
| Authors: | T. Ritter. |
| Date: | 1 April 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6217 |
|
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan AreaNetworks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. |
|
| |
| RFC 6218 | Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material |
| |
| Authors: | G. Zorn, T. Zhang, J. Walker, J. Salowey. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6218 |
|
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. |
|
| |
| RFC 6219 | The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition |
| |
| Authors: | X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6219 |
|
This document presents the China Education and Research Network(CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP'sIPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the globalIPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. |
|
| |
| RFC 6220 | Defining the Role and Function of IETF Protocol Parameter Registry Operators |
| |
| Authors: | D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8722 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6220 |
|
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. |
|
| |
| RFC 6221 | Lightweight DHCPv6 Relay Agent |
| |
| Authors: | D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh. |
| Date: | May 2011 |
| Formats: | txt json html |
| Updates: | RFC 3315 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6221 |
|
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link AccessMultiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. |
|
| |
| RFC 6222 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
|
|
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 are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCPCNAMEs. |
|
| |
| RFC 6223 | Indication of Support for Keep-Alive |
| |
| Authors: | C. Holmberg. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6223 |
|
This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network AddressTranslation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. |
|
| |
| RFC 6224 | Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains |
| |
| Authors: | T. Schmidt, M. Waehlisch, S. Krishnan. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6224 |
|
This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents inMobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. |
|
| |
| RFC 6225 | Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information |
| |
| Authors: | J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed.. |
| Date: | July 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3825 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6225 |
|
This document specifies Dynamic Host Configuration Protocol options(both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includesLatitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. |
|
| |
| RFC 6226 | PIM Group-to-Rendezvous-Point Mapping |
| |
| Authors: | B. Joshi, A. Kessler, D. McWalter. |
| Date: | May 2011 |
| Formats: | txt html json |
| Updates: | RFC 4601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6226 |
|
Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintainsGroup-to-RP mappings that are used to identify a Rendezvous Point(RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group.This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. |
|
| |
| RFC 6227 | Design Goals for Scalable Internet Routing |
| |
| Authors: | T. Li, Ed.. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6227 |
|
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi- homing, and inter-domain traffic engineering. The Routing ResearchGroup is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. |
|
| |
| RFC 6228 | Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog |
| |
| Authors: | C. Holmberg. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6228 |
|
This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. |
|
| |
| RFC 6229 | Test Vectors for the Stream Cipher RC4 |
| |
| Authors: | J. Strombergson, S. Josefsson. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6229 |
|
This document contains test vectors for the stream cipher RC4. |
|
| |
| RFC 6230 | Media Control Channel Framework |
| |
| Authors: | C. Boulton, T. Melanchuk, S. McGlashan. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6230 |
|
This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.
The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. |
|
| |
| RFC 6231 | An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework |
| |
| Authors: | S. McGlashan, T. Melanchuk, C. Boulton. |
| Date: | May 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6623 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6231 |
|
This document defines a Media Control Channel Framework Package forInteractive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. |
|
| |
| RFC 6232 | Purge Originator Identification TLV for IS-IS |
| |
|
|
At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge.This makes it difficult to locate the source IS.
To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normalLink State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.
This document updates RFC 5301, RFC 5304, and RFC 5310. |
|
| |
| RFC 6233 | IS-IS Registry Extension for Purges |
| |
|
|
IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS ProtocolData Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. |
|
| |
| RFC 6234 | US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) |
| |
|
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), namely SHA-224, SHA-256,SHA-384, and SHA-512. This document makes open source code performing these SHA hash functions conveniently available to theInternet community. The sample code supports input strings of arbitrary bit length. Much of the text herein was adapted by the authors from FIPS 180-2.
This document replaces RFC 4634, fixing errata and adding code for anHMAC-based extract-and-expand Key Derivation Function, HKDF (RFC5869). As with RFC 4634, code to perform SHA-based Hashed MessageAuthentication Codes (HMACs) is also included. |
|
| |
| RFC 6235 | IP Flow Anonymization Support |
| |
| Authors: | E. Boschi, B. Trammell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6235 |
|
This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export(IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. |
|
| |
| RFC 6236 | Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) |
| |
| Authors: | I. Johansson, K. Jung. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6236 |
|
This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. |
|
| |
| RFC 6237 | IMAP4 Multimailbox SEARCH Extension |
| |
|
|
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields inESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. |
|
| |
| RFC 6238 | TOTP: Time-Based One-Time Password Algorithm |
| |
| Authors: | D. M'Raihi, S. Machani, M. Pei, J. Rydell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6238 |
|
This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. TheHOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.
The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access andWi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. |
|
| |
| RFC 6239 | Suite B Cryptographic Suites for Secure Shell (SSH) |
| |
|
|
This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and theSecure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the AdvancedEncryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), andX.509 certificates. |
|
| |
| RFC 6240 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 |
| |
| Authors: | D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed.. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6240 |
|
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 for modeling SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). |
|
| |
| RFC 6241 | Network Configuration Protocol (NETCONF) |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletesRFC 4741. |
|
| |
| RFC 6242 | Using the NETCONF Protocol over Secure Shell (SSH) |
| |
|
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. |
|
| |
| RFC 6243 | With-defaults Capability for NETCONF |
| |
| Authors: | A. Bierman, B. Lengyel. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6243 |
|
The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. |
|
| |
| RFC 6244 | An Architecture for Network Management Using NETCONF and YANG |
| |
| Authors: | P. Shafer. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6244 |
|
The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. |
|
| |
| RFC 6245 | Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 |
| |
| Authors: | P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6245 |
|
The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new MobileIP extension that is used to exchange the value to be used in the GREKey field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to requestGRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple VirtualPrivate Networks (VPNs), which may have overlapping home addresses.When the tuple <Care of Address, Home Address, and Home AgentAddress&rt; is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when usingIP-in-IP tunneling. |
|
| |
| RFC 6246 | Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges |
| |
| Authors: | A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6246 |
|
One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.
When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in theIEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module andIETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. |
|
| |
| RFC 6247 | Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status |
| |
|
|
This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, andRFC 1693. |
|
| |
| RFC 6248 | RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete |
| |
|
|
This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM)Metrics Registry", as Obsolete, and withdraws the IANA IPPM MetricsRegistry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. |
|
| |
| RFC 6249 | Metalink/HTTP: Mirrors and Hashes |
| |
| Authors: | A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6249 |
|
This document specifies Metalink/HTTP: Mirrors and CryptographicHashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations(mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements forMetalink/HTTP clients and servers are described here. |
|
| |
| RFC 6250 | Evolution of the IP Model |
| |
| Authors: | D. Thaler. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6250 |
|
This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were(and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. |
|
| |
| RFC 6251 | Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol |
| |
| Authors: | S. Josefsson. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6251 |
|
This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. |
|
| |
| RFC 6252 | A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization |
| |
| Authors: | A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6252 |
|
This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover.MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.
This document is a product of the IP Mobility Optimizations (MOBOPTS)Research Group. |
|
| |
| RFC 6253 | Host Identity Protocol Certificates |
| |
|
|
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies theCERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) andSimple Public Key Infrastructure (SPKI) certificates.
The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 5201. |
|
| |
| RFC 6254 | Request to Move RFC 2754 to Historic Status |
| |
|
|
RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System.In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. |
|
| |
| RFC 6255 | Delay-Tolerant Networking Bundle Protocol IANA Registries |
| |
| Authors: | M. Blanchet. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6255 |
|
The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and LickliderTransmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries toIANA for official custody. This document describes the actions executed by IANA. |
|
| |
| RFC 6256 | Using Self-Delimiting Numeric Values in Protocols |
| |
| Authors: | W. Eddy, E. Davies. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6256 |
|
Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of theDelay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6257 | Bundle Security Protocol Specification |
| |
| Authors: | S. Symington, S. Farrell, H. Weiss, P. Lovell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6257 |
|
This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol.Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6258 | Delay-Tolerant Networking Metadata Extension Block |
| |
| Authors: | S. Symington. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6258 |
|
This document defines an extension block that may be used with theDelay-Tolerant Networking (DTN) Bundle Protocol. This MetadataExtension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as anRFC were raised. |
|
| |
| RFC 6259 | Delay-Tolerant Networking Previous-Hop Insertion Block |
| |
| Authors: | S. Symington. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6259 |
|
This document defines an extension block for use with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Previous-HopInsertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols(e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6260 | Compressed Bundle Header Encoding (CBHE) |
| |
| Authors: | S. Burleigh. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6260 |
|
This document describes a convention by which Delay-TolerantNetworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing.Therefore, it has no impact on the interoperability of differentBundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6261 | Encrypted Signaling Transport Modes for the Host Identity Protocol |
| |
| Authors: | A. Keranen. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6261 |
|
This document specifies two transport modes for Host IdentityProtocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. |
|
| |
| RFC 6262 | RTP Payload Format for IP-MR Speech Codec |
| |
| Authors: | S. Ikonin. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6262 |
|
This document specifies the payload format for packetization ofSPIRIT IP-MR encoded speech signals into the Real-time TransportProtocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. |
|
| |
| RFC 6263 | Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows |
| |
| Authors: | X. Marjou, A. Sollaud. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6263 |
|
This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP ControlProtocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to InteractiveConnectivity Establishment (ICE) agents. |
|
| |
| RFC 6264 | An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition |
| |
| Authors: | S. Jiang, D. Guo, B. Carpenter. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6264 |
|
Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.
This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts andIPv4 access services for IPv4 hosts while leaving much of a legacyISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. |
|
| |
| RFC 6265 | HTTP State Management Mechanism |
| |
|
|
This document defines the HTTP Cookie and Set-Cookie header fields.These header fields can be used by HTTP servers to store state(called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. |
|
| |
| RFC 6266 | Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) |
| |
|
|
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. |
|
| |
| RFC 6267 | MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | V. Cakulev, G. Sundaram. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6267 |
|
This document describes a key management protocol variant for theMultimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizesIdentity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. |
|
| |
| RFC 6268 | Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) |
| |
|
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 6269 | Issues with IP Address Sharing |
| |
| Authors: | M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6269 |
|
The completion of IPv4 address allocations from IANA and the RegionalInternet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. |
|
| |
| RFC 6270 | The 'tn3270' URI Scheme |
| |
|
|
This document is the specification of the 'tn3270' Uniform ResourceIdentifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned thisURI scheme without defining its syntax and semantics. |
|
| |
| RFC 6271 | Requirements for SIP-Based Session Peering |
| |
| Authors: | J-F. Mule. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6271 |
|
This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. |
|
| |
| RFC 6272 | Internet Protocols for the Smart Grid |
| |
| Authors: | F. Baker, D. Meyer. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6272 |
|
This note identifies the key infrastructure protocols of the InternetProtocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriateInternet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for SmartGrid deployment from the picture presented here. |
|
| |
| RFC 6273 | The Secure Neighbor Discovery (SEND) Hash Threat Analysis |
| |
| Authors: | A. Kukec, S. Krishnan, S. Jiang. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6273 |
|
This document analyzes the use of hashes in Secure Neighbor Discovery(SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. |
|
| |
| RFC 6274 | Security Assessment of the Internet Protocol Version 4 |
| |
| Authors: | F. Gont. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6274 |
|
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). |
|
| |
| RFC 6275 | Mobility Support in IPv6 |
| |
| Authors: | C. Perkins, Ed., D. Johnson, J. Arkko. |
| Date: | July 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3775 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6275 |
|
This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enablesIPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. |
|
| |
| RFC 6276 | DHCPv6 Prefix Delegation for Network Mobility (NEMO) |
| |
| Authors: | R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6276 |
|
One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. |
|
| |
| RFC 6277 | Online Certificate Status Protocol Algorithm Agility |
| |
|
|
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. |
|
| |
| RFC 6278 | Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax |
| |
| Authors: | J. Herzog, R. Khazan. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6278 |
|
This document describes how to use the 'static-static Elliptic CurveDiffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. |
|
| |
| RFC 6279 | Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement |
| |
| Authors: | M. Liebsch, Ed., S. Jeong, Q. Wu. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6279 |
|
Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their LocalMobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy MobileIPv6. |
|
| |
| RFC 6280 | An Architecture for Location and Location Privacy in Internet Applications |
| |
|
|
Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. |
|
| |
| RFC 6281 | Understanding Apple's Back to My Mac (BTMM) Service |
| |
| Authors: | S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6281 |
|
This document describes the implementation of Apple Inc.'s Back to MyMac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators(NATs) and mobility of devices. |
|
| |
| RFC 6282 | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks |
| |
|
|
This document updates RFC 4944, "Transmission of IPv6 Packets overIEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power WirelessPersonal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope.This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. |
|
| |
| RFC 6283 | Extensible Markup Language Evidence Record Syntax (XMLERS) |
| |
| Authors: | A. Jerman Blazic, S. Saljic, T. Gondrom. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6283 |
|
In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The ExtensibleMarkup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax NotationOne) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. |
|
| |
| RFC 6284 | Port Mapping between Unicast and Multicast RTP Sessions |
| |
| Authors: | A. Begen, D. Wing, T. Van Caenegem. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6284 |
|
This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. |
|
| |
| RFC 6285 | Unicast-Based Rapid Acquisition of Multicast RTP Sessions |
| |
| Authors: | B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6285 |
|
When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as theAcquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and RTPControl Protocol (RTCP) machinery that reduces the acquisition delay.In this method, an auxiliary unicast RTP session carrying theReference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition.The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. |
|
| |
| RFC 6286 | Autonomous-System-Wide Unique BGP Identifier for BGP-4 |
| |
|
|
To accommodate situations where the current requirements for the BGPIdentifier are not met, this document relaxes the definition of theBGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System- wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. |
|
| |
| RFC 6287 | OCRA: OATH Challenge-Response Algorithm |
| |
| Authors: | D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6287 |
|
This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication(OATH). The specified mechanisms leverage the HMAC-based One-TimePassword (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. |
|
| |
| RFC 6288 | URN Namespace for the Defence Geospatial Information Working Group (DGIWG) |
| |
| Authors: | C. Reed. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6288 |
|
This document describes the Namespace Identifier (NID) for UniformResource Name (URN) Namespace resources published by the DefenceGeospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.
Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). |
|
| |
| RFC 6289 | A Uniform Resource Name (URN) Namespace for CableLabs |
| |
| Authors: | E. Cardona, S. Channabasappa, J-F. Mule. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6289 |
|
This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs).CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' AssignedNames and Numbers registry. |
|
| |
| RFC 6290 | A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6290 |
|
This document describes an extension to the Internet Key ExchangeProtocol version 2 (IKEv2) that allows for faster detection ofSecurity Association (SA) desynchronization using a saved token.
When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. |
|
| |
| RFC 6291 | Guidelines for the Use of the "OAM" Acronym in the IETF |
| |
| Authors: | L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield. |
| Date: | June 2011 |
| Formats: | txt html json |
| Also: | BCP 0161 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6291 |
|
At first glance, the acronym "OAM" seems to be well-known and well- understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.
This document provides a definition of the acronym "OAM" (Operations,Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. |
|
| |
| RFC 6292 | Requirements for a Working Group Charter Tool |
| |
|
|
The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. |
|
| |
| RFC 6293 | Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker |
| |
| Authors: | P. Hoffman. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6293 |
|
The document gives a set of requirements for extending the IETFDatatracker to give individual IETF community members, including theIETF leadership, easy methods for tracking the progress of theInternet-Drafts and RFCs of interest to them. |
|
| |
| RFC 6294 | Survey of Proposed Use Cases for the IPv6 Flow Label |
| |
| Authors: | Q. Hu, B. Carpenter. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6294 |
|
The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. |
|
| |
| RFC 6295 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | June 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 4695 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6295 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. This document obsoletes RFC 4695. |
|
| |
| RFC 6296 | IPv6-to-IPv6 Network Prefix Translation |
| |
| Authors: | M. Wasserman, F. Baker. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6296 |
|
This document describes a stateless, transport-agnostic IPv6-to-IPv6Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT(NAPT44) and provides a 1:1 relationship between addresses in the"inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. |
|
| |
| RFC 6297 | A Survey of Lower-than-Best-Effort Transport Protocols |
| |
| Authors: | M. Welzl, D. Ros. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6297 |
|
This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standardTCP than standard TCP itself when they share a bottleneck with it.Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or"lower than") best-effort service. |
|
| |
| RFC 6298 | Computing TCP's Retransmission Timer |
| |
|
|
This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion inSection 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. |
|
