| |
| RFC 6101 | The Secure Sockets Layer (SSL) Protocol Version 3.0 |
| |
| Authors: | A. Freier, P. Karlton, P. Kocher. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6101 |
|
This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.
This document specifies version 3.0 of the Secure Sockets Layer (SSL3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 6104 | Rogue IPv6 Router Advertisement Problem Statement |
| |
| Authors: | T. Chown, S. Venaas. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6104 |
|
When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. |
|
| |
| RFC 6105 | IPv6 Router Advertisement Guard |
| |
| Authors: | E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. |
| Date: | February 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7113 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6105 |
|
Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. |
|
| |
| RFC 6106 | IPv6 Router Advertisement Options for DNS Configuration |
| |
| Authors: | J. Jeong, S. Park, L. Beloeil, S. Madanapalli. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 5006 |
| Obsoleted by: | RFC 8106 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6106 |
|
This document specifies IPv6 Router Advertisement options to allowIPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. |
|
| |
| RFC 6107 | Procedures for Dynamically Signaled Hierarchical Label Switched Paths |
| |
|
|
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process.
The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206. |
|
| |
| RFC 6108 | Comcast's Web Notification System Design |
| |
| Authors: | C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6108 |
|
The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection.There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. |
|
| |
| RFC 6109 | La Posta Elettronica Certificata - Italian Certified Electronic Mail |
| |
| Authors: | C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6109 |
|
Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "PostaElettronica Certificata") were defined, giving the system legal standing.
The design of the entire system was carried out by the NationalCenter for Informatics in the Public Administration of Italy(DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National ResearchCouncil (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. |
|
| |
| RFC 6110 | Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content |
| |
|
|
This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG),Schematron, and Schematron and Document Schema Renaming Language(DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.Procedures for schema-based validation of such documents are also discussed. |
|
| |
| RFC 6111 | Additional Kerberos Naming Constraints |
| |
|
|
This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. |
|
| |
| RFC 6112 | Anonymity Support for Kerberos |
| |
|
|
This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. |
|
| |
| RFC 6113 | A Generalized Framework for Kerberos Pre-Authentication |
| |
|
|
Kerberos is a protocol for verifying the identity of principals(e.g., a workstation user or a network server) on an open network.The Kerberos protocol provides a facility called pre-authentication.Pre-authentication mechanisms can use this facility to extend theKerberos protocol and prove the identity of a principal.
This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre- authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.
This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. |
|
| |
| RFC 6114 | The 128-Bit Blockcipher CLEFIA |
| |
| Authors: | M. Katagi, S. Moriai. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6114 |
|
This document describes the specification of the blockcipher CLEFIA.CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and256 bits, which is compatible with the interface of the AdvancedEncryption Standard (AES). The algorithm of CLEFIA was published in2007, and its security has been scrutinized in the public community.CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to theInternet, which will be connected to more distributed and constrained devices. |
|
| |
| RFC 6115 | Recommendation for a Routing Architecture |
| |
| Authors: | T. Li, Ed.. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6115 |
|
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. |
|
| |
| RFC 6116 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
| Authors: | S. Bradner, L. Conroy, K. Fujiwara. |
| Date: | March 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6116 |
|
This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. |
|
| |
| RFC 6117 | IANA Registration of Enumservices: Guide, Template, and IANA Considerations |
| |
| Authors: | B. Hoeneisen, A. Mayrhofer, J. Livingood. |
| Date: | March 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6117 |
|
This document specifies a revision of the IANA RegistrationGuidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating EnumserviceSpecifications. |
|
| |
| RFC 6118 | Update of Legacy IANA Registrations of Enumservices |
| |
| Authors: | B. Hoeneisen, A. Mayrhofer. |
| Date: | March 2011 |
| Formats: | txt html json |
| Updates: | RFC 3762, RFC 3764, RFC 3953, RFC 4143, RFC 4002, RFC 4238, RFC 4355, RFC 4415, RFC 4769, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5333 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6118 |
|
This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. |
|
| |
| RFC 6119 | IPv6 Traffic Engineering in IS-IS |
| |
| Authors: | J. Harrison, J. Berger, M. Bartlett. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6119 |
|
This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic- engineered routes using IPv6 addresses. |
|
| |
| RFC 6120 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document definesXMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. |
|
| |
| RFC 6121 | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence |
| |
|
|
This document defines extensions to core features of the ExtensibleMessaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. |
|
| |
| RFC 6122 | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
|
This document defines the format for addresses used in the ExtensibleMessaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. |
|
| |
| RFC 6123 | Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts |
| |
| Authors: | A. Farrel. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6123 |
|
It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal.Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.
The Operations Area has developed "Guidelines for ConsideringOperations and Management of New Protocols and Protocol Extensions"(RFC 5706), and those guidelines have been adopted by the PathComputation Element (PCE) Working Group.
Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. |
|
| |
| RFC 6124 | An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol |
| |
| Authors: | Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6124 |
|
The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. |
|
| |
| RFC 6125 | Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) |
| |
| Authors: | P. Saint-Andre, J. Hodges. |
| Date: | March 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6125 |
|
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509(PKIX) certificates in the context of Transport Layer Security (TLS).This document specifies procedures for representing and verifying the identity of application services in such interactions. |
|
| |
| RFC 6126 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. |
|
| |
| RFC 6127 | IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios |
| |
| Authors: | J. Arkko, M. Townsley. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6127 |
|
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.
This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on newIPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. |
|
| |
| RFC 6128 | RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions |
| |
|
|
The Session Description Protocol (SDP) has an attribute that allowsRTP applications to specify an address and a port associated with theRTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. |
|
| |
| RFC 6129 | The 'application/tei+xml' Media Type |
| |
| Authors: | L. Romary, S. Lundberg. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6129 |
|
This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding andInterchange guidelines. |
|
| |
| RFC 6130 | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
|
|
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). |
|
| |
| RFC 6131 | Sieve Vacation Extension: "Seconds" Parameter |
| |
| Authors: | R. George, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6131 |
|
This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. |
|
| |
| RFC 6132 | Sieve Notification Using Presence Information |
| |
| Authors: | R. George, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6132 |
|
This is a further extension to the Sieve mail filtering languageNotification extension, defining presence information that may be checked through the notify_method_capability feature. |
|
| |
| RFC 6133 | Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality |
| |
| Authors: | R. George, B. Leiba, A. Melnikov. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6133 |
|
This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. |
|
| |
| RFC 6134 | Sieve Extension: Externally Stored Lists |
| |
| Authors: | A. Melnikov, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6134 |
|
The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.
This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol(LDAP), the Application Configuration Access Protocol (ACAP), vCardExtensions to WebDAV (CardDAV), or relational databases. |
|
| |
| RFC 6135 | An Alternative Connection Model for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | C. Holmberg, S. Blau. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6135 |
|
This document defines an alternative connection model for MessageSession Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create theMSRP transport connection. The model allows MSRP UAs behind NetworkAddress Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. |
|
| |
| RFC 6136 | Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework |
| |
| Authors: | A. Sajassi, Ed., D. Mohan, Ed.. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6136 |
|
This document provides framework and requirements for Layer 2 VirtualPrivate Network (L2VPN) Operations, Administration, and Maintenance(OAM). The OAM framework is intended to provide OAM layering acrossL2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements forL2VPN services, i.e., Virtual Private LAN Service (VPLS), VirtualPrivate Wire Service (VPWS), and IP-only LAN Service (IPLS).Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSNOAM requirements are also identified. |
|
| |
| RFC 6137 | The Network Trouble Ticket Data Model (NTTDM) |
| |
| Authors: | D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6137 |
|
Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. TheTT systems of the participants collect, represent, and disseminate TT information in different formats.
As a result, management of the daily workload by a central NetworkOperation Centre (NOC) is a challenge on its own. Normalization ofTTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE(Enabling Grids for E-sciencE) project. |
|
| |
| RFC 6138 | LDP IGP Synchronization for Broadcast Networks |
| |
|
|
RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior GatewayProtocol (IGP) is operational on a link but Label DistributionProtocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use- case without dropping traffic. The mechanism does not introduce any protocol message changes. |
|
| |
| RFC 6139 | Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios |
| |
| Authors: | S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6139 |
|
"Routing and Addressing in Networks with Global Enterprise Recursion(RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. |
|
| |
| RFC 6140 | Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) |
| |
|
|
This document defines a mechanism by which a Session InitiationProtocol (SIP) server acting as a traditional Private Branch Exchange(PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.This document therefore focuses on this use case. |
|
| |
| RFC 6141 | Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, Ed., C. Holmberg, Y. Gao. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6141 |
|
The procedures for handling SIP re-INVITEs are described in RFC 3261.Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. |
|
| |
| RFC 6142 | ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP |
| |
| Authors: | A. Moise, J. Brodkin. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6142 |
|
This RFC provides a framework for transporting ANSI C12.22/IEEE1703/MC12.22 Advanced Metering Infrastructure (AMI) Application LayerMessages on an IP network.
This document is not an official submission on behalf of the ANSIC12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. |
|
| |
| RFC 6143 | The Remote Framebuffer Protocol |
| |
| Authors: | T. Richardson, J. Levine. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6143 |
|
RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. |
|
| |
| RFC 6144 | Framework for IPv4/IPv6 Translation |
| |
| Authors: | F. Baker, X. Li, C. Bao, K. Yin. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6144 |
|
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - ProtocolTranslation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. |
|
| |
| RFC 6145 | IP/ICMP Translation Algorithm |
| |
|
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 2765. |
|
| |
| RFC 6146 | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
| Authors: | M. Bagnulo, P. Matthews, I. van Beijnum. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6146 |
|
This document describes stateful NAT64 translation, which allowsIPv6-only clients to contact IPv4 servers using unicast UDP, TCP, orICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When statefulNAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. |
|
| |
| RFC 6147 | DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers |
| |
| Authors: | M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6147 |
|
DNS64 is a mechanism for synthesizing AAAA records from A records.DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. |
|
| |
| RFC 6148 | DHCPv4 Lease Query by Relay Agent Remote ID |
| |
| Authors: | P. Kurapati, R. Desetti, B. Joshi. |
| Date: | February 2011 |
| Formats: | txt json html |
| Updates: | RFC 4388 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6148 |
|
Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. |
|
| |
| RFC 6149 | MD2 to Historic Status |
| |
|
|
This document retires MD2 and discusses the reasons for doing so.This document moves RFC 1319 to Historic status. |
|
| |
| RFC 6150 | MD4 to Historic Status |
| |
|
|
This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. |
|
| |
| RFC 6151 | Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms |
| |
|
|
This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations forHMAC-MD5. |
|
| |
| RFC 6152 | SMTP Service Extension for 8-bit MIME Transport |
| |
|
|
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of theUS-ASCII octet range (hex 00-7F) may be relayed using SMTP. |
|
| |
| RFC 6153 | DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery |
| |
| Authors: | S. Das, G. Bajko. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6153 |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover AccessNetwork Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third GenerationPartnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes(MNs). |
|
| |
| RFC 6154 | IMAP LIST Extension for Special-Use Mailboxes |
| |
| Authors: | B. Leiba, J. Nicolson. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6154 |
|
Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. |
|
| |
| RFC 6155 | Use of Device Identity in HTTP-Enabled Location Delivery (HELD) |
| |
| Authors: | J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6915 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6155 |
|
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. |
|
| |
| RFC 6156 | Traversal Using Relays around NAT (TURN) Extension for IPv6 |
| |
| Authors: | G. Camarillo, O. Novo, S. Perreault, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8656 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6156 |
|
This document adds IPv6 support to Traversal Using Relays around NAT(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type theTURN server will allocate (e.g., an IPv4-only node may request theTURN server to allocate an IPv6 address). |
|
| |
| RFC 6157 | IPv6 Transition in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, K. El Malki, V. Gurbani. |
| Date: | April 2011 |
| Formats: | txt html json |
| Updates: | RFC 3264 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6157 |
|
This document describes how the IPv4 Session Initiation Protocol(SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack(i.e., IPv4-only and IPv4/IPv6) user agents are considered. |
|
| |
| RFC 6158 | RADIUS Design Guidelines |
| |
|
|
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). |
|
| |
| RFC 6159 | Session-Specific Explicit Diameter Request Routing |
| |
| Authors: | T. Tsou, G. Zorn, T. Taylor, Ed.. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6159 |
|
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting aDiameter session. |
|
| |
| RFC 6160 | Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types |
| |
| Authors: | S. Turner. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6160 |
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData. |
|
| |
| RFC 6161 | Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
|
|
This document describes the conventions for using several EllipticCurve cryptographic algorithms with the Cryptographic Message Syntax(CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 6033. |
|
| |
| RFC 6162 | Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type |
| |
|
|
This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 5959. |
|
| |
| RFC 6163 | Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6163 |
|
This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element(PCE) architecture to the control of Wavelength Switched OpticalNetworks (WSONs). In particular, it examines Routing and WavelengthAssignment (RWA) of optical paths.
This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. |
|
| |
| RFC 6164 | Using 127-Bit IPv6 Prefixes on Inter-Router Links |
| |
| Authors: | M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. |
| Date: | April 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6547 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6164 |
|
On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. |
|
| |
| RFC 6165 | Extensions to IS-IS for Layer-2 Systems |
| |
| Authors: | A. Banerjee, D. Ward. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6165 |
|
This document specifies the Intermediate System to IntermediateSystem (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs(TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. |
|
| |
| RFC 6166 | A Registry for PIM Message Types |
| |
|
|
This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types.It also specifies a procedure for registering new types.
In addition to this, one message type is reserved, and may be used for a future extension of the message type space. |
|
| |
| RFC 6167 | URI Scheme for Java(tm) Message Service 1.0 |
| |
| Authors: | M. Phillips, P. Adams, D. Rokicki, E. Johnson. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6167 |
|
This document defines the format of Uniform Resource Identifiers(URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS).It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMSURI is not compatible with previously existing, but unregistered,"jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. |
|
| |
| RFC 6168 | Requirements for Management of Name Servers for the DNS |
| |
| Authors: | W. Hardaker. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6168 |
|
Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. |
|
| |
| RFC 6169 | Security Concerns with IP Tunneling |
| |
| Authors: | S. Krishnan, D. Thaler, J. Hoagland. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6169 |
|
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. |
|
| |
| RFC 6170 | Internet X.509 Public Key Infrastructure -- Certificate Image |
| |
| Authors: | S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. |
| Date: | May 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9399 |
| Updates: | RFC 3709 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6170 |
|
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. |
|
| |
| RFC 6171 | The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control |
| |
| Authors: | K. Zeilenga. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6171 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. |
|
| |
| RFC 6172 | Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode |
| |
|
|
Changes to Fibre Channel have caused the specification of theInternet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.
This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre ChannelInternet Protocol (FCIP). |
|
| |
| RFC 6173 | Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) |
| |
|
|
This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.
This document obsoletes RFC 4369. |
|
| |
| RFC 6174 | Definition of IETF Working Group Document States |
| |
| Authors: | E. Juskevicius. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6174 |
|
The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.
This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and theirDelegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. |
|
| |
| RFC 6175 | Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors |
| |
| Authors: | E. Juskevicius. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6175 |
|
This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for WorkingGroup (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use theDatatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. |
|
| |
| RFC 6176 | Prohibiting Secure Sockets Layer (SSL) Version 2.0 |
| |
|
|
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport LayerSecurity (TLS). |
|
| |
| RFC 6177 | IPv6 Address Assignment to End Sites |
| |
|
|
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005.This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177.Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
This document obsoletes RFC 3177. |
|
| |
| RFC 6178 | Label Edge Router Forwarding of IPv4 Option Packets |
| |
| Authors: | D. Smith, J. Mullooly, W. Jaeger, T. Scholl. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updates: | RFC 3031 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6178 |
|
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in differentLER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class(FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulateIPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. |
|
| |
| RFC 6179 | The Internet Routing Overlay Network (IRON) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6179 |
|
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes anInternet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of theIRTF Routing Research Group. |
|
| |
| RFC 6180 | Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment |
| |
| Authors: | J. Arkko, F. Baker. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6180 |
|
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. |
|
| |
| RFC 6181 | Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | M. Bagnulo. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6181 |
|
Multipath TCP (MPTCP for short) describes the extensions proposed forTCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multipleIP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. |
|
| |
| RFC 6182 | Architectural Guidelines for Multipath TCP Development |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6182 |
|
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of aMultipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. |
|
| |
| RFC 6183 | IP Flow Information Export (IPFIX) Mediation: Framework |
| |
| Authors: | A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi. |
| Date: | April 2011 |
| Formats: | txt html json |
| Updates: | RFC 5470 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6183 |
|
This document describes a framework for IP Flow Information Export(IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. |
|
| |
| RFC 6184 | RTP Payload Format for H.264 Video |
| |
| Authors: | Y.-K. Wang, R. Even, T. Kristensen, R. Jesup. |
| Date: | May 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3984 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6184 |
|
This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec, excluding theScalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere.The RTP payload format allows for packetization of one or moreNetwork Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. |
|
| |
| RFC 6185 | RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video |
| |
| Authors: | T. Kristensen, P. Luthi. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6185 |
|
This document describes an RTP payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing.The RCDO RTP payload format is based on the H.264 RTP payload format. |
|
| |
| RFC 6186 | Use of SRV Records for Locating Email Submission/Access Services |
| |
|
|
This specification describes how SRV records can be used to locate email services. |
|
| |
| RFC 6187 | X.509v3 Certificates for Secure Shell Authentication |
| |
| Authors: | K. Igoe, D. Stebila. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6187 |
|
X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. |
|
| |
| RFC 6188 | The Use of AES-192 and AES-256 in Secure RTP |
| |
| Authors: | D. McGrew. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6188 |
|
This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure RealtimeTransport Control Protocol (SRTCP) and a new SRTP Key DerivationFunction (KDF) for AES-192 and AES-256. |
|
| |
| RFC 6189 | ZRTP: Media Path Key Agreement for Unicast Secure RTP |
| |
| Authors: | P. Zimmermann, A. Johnston, Ed., J. Callas. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6189 |
|
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume aPublic Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a SessionDescription Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effortSRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles.ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. |
|
| |
| RFC 6190 | RTP Payload Format for Scalable Video Coding |
| |
| Authors: | S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6190 |
|
This memo describes an RTP payload format for Scalable Video Coding(SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC InternationalStandard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multipleRTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. |
|
| |
| RFC 6191 | Reducing the TIME-WAIT State Using TCP Timestamps |
| |
|
|
This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. |
|
| |
| RFC 6192 | Protecting the Router Control Plane |
| |
| Authors: | D. Dugal, C. Pignataro, R. Dunn. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6192 |
|
This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. |
|
| |
| RFC 6193 | Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) |
| |
| Authors: | M. Saito, D. Wing, M. Toyama. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6193 |
|
This document specifies how to establish a media session that represents a virtual private network using the Session InitiationProtocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the SessionDescription Protocol (SDP) so that it can negotiate use of theInternet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. |
|
| |
| RFC 6194 | Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms |
| |
| Authors: | T. Polk, L. Chen, S. Turner, P. Hoffman. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6194 |
|
This document includes security considerations for the SHA-0 andSHA-1 message digest algorithm. |
|
| |
| RFC 6195 | Domain Name System (DNS) IANA Considerations |
| |
|
|
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 6196 | Moving mailserver: URI Scheme to Historic |
| |
|
|
This document registers the mailserver: URI scheme as historic in theIANA URI registry. |
|
| |
| RFC 6197 | Location-to-Service Translation (LoST) Service List Boundary Extension |
| |
| Authors: | K. Wolf. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6197 |
|
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation&rt; query to the LoST server.However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines aService List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. |
|
| |
| RFC 6198 | Requirements for the Graceful Shutdown of BGP Sessions |
| |
| Authors: | B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6198 |
|
The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications(e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown.This document expresses requirements for such a solution. |
|
