| |
| RFC 5701 | IPv6 Address Specific BGP Extended Community Attribute |
| |
|
|
Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support anIPv6 Address Specific Extended Community. The lack of an IPv6Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address SpecificExtended Community, that addresses this problem. The IPv6 AddressSpecific Extended Community is similar to the IPv4 Address SpecificExtended Community, except that it carries an IPv6 address rather than an IPv4 address. |
|
| |
| RFC 5702 | Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
|
|
This document describes how to produce RSA/SHA-256 and RSA/SHA-512DNSKEY and RRSIG resource records for use in the Domain Name SystemSecurity Extensions (RFC 4033, RFC 4034, and RFC 4035). |
|
| |
| RFC 5703 | Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure |
| |
| Authors: | T. Hansen, C. Daboo. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5703 |
|
This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. |
|
| |
| RFC 5704 | Uncoordinated Protocol Development Considered Harmful |
| |
| Authors: | S. Bryant, Ed., M. Morrow, Ed., IAB. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5704 |
|
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team onMPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETFRFCs.
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. |
|
| |
| RFC 5705 | Keying Material Exporters for Transport Layer Security (TLS) |
| |
|
|
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. |
|
| |
| RFC 5706 | Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions |
| |
| Authors: | D. Harrington. |
| Date: | November 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5706 |
|
New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal.The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. |
|
| |
| RFC 5707 | Media Server Markup Language (MSML) |
| |
| Authors: | A. Saleem, Y. Xin, G. Sharratt. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5707 |
|
The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants usingVoiceXML. |
|
| |
| RFC 5708 | X.509 Key and Signature Encoding for the KeyNote Trust Management System |
| |
| Authors: | A. Keromytis. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5708 |
|
This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer orLicensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.
In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). |
|
| |
| RFC 5709 | OSPFv2 HMAC-SHA Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updates: | RFC 2328 |
| Updated by: | RFC 7474 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5709 |
|
This document describes how the National Institute of Standards andTechnology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. |
|
| |
| RFC 5710 | PathErr Message Triggered MPLS and GMPLS LSP Reroutes |
| |
| Authors: | L. Berger, D. Papadimitriou, JP. Vasseur. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5710 |
|
This document describes how Resource ReserVation Protocol (RSVP)PathErr messages may be used to trigger rerouting of Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) point-to-pointTraffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existingStandards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. |
|
| |
| RFC 5711 | Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages |
| |
| Authors: | JP. Vasseur, Ed., G. Swallow, I. Minei. |
| Date: | January 2010 |
| Formats: | txt json html |
| Updates: | RFC 3209 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5711 |
|
The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource ReservationProtocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS(GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. |
|
| |
| RFC 5712 | MPLS Traffic Engineering Soft Preemption |
| |
| Authors: | M. Meyer, Ed., JP. Vasseur, Ed.. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5712 |
|
This document specifies Multiprotocol Label Switching (MPLS) TrafficEngineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering LabelSwitched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until theTE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. |
|
| |
| RFC 5713 | Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) |
| |
| Authors: | H. Moustafa, H. Tschofenig, S. De Cnodder. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5713 |
|
The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line AccessMultiplexer (DSLAM)). The main goal of this protocol is to allow theNAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.
This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model forANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the AccessNode Control Protocol are defined. |
|
| |
| RFC 5714 | IP Fast Reroute Framework |
| |
| Authors: | M. Shand, S. Bryant. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5714 |
|
This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. |
|
| |
| RFC 5715 | A Framework for Loop-Free Convergence |
| |
| Authors: | M. Shand, S. Bryant. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5715 |
|
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. |
|
| |
| RFC 5716 | Requirements for Federated File Systems |
| |
| Authors: | J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5716 |
|
This document describes and lists the functional requirements of a federated file system and defines related terms. |
|
| |
| RFC 5717 | Partial Lock Remote Procedure Call (RPC) for NETCONF |
| |
| Authors: | B. Lengyel, M. Bjorklund. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5717 |
|
The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. |
|
| |
| RFC 5718 | An In-Band Data Communication Network For the MPLS Transport Profile |
| |
| Authors: | D. Beller, A. Farrel. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5718 |
|
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based onMPLS packet switching technology.
This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management CommunicationNetwork (MCN) and a Signaling Communication Network (SCN).Collectively, the MCN and SCN may be referred to as the DataCommunication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. |
|
| |
| RFC 5719 | Updated IANA Considerations for Diameter Command Code Allocations |
| |
|
|
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. |
|
| |
| RFC 5720 | Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) |
| |
| Authors: | F. Templin. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5720 |
|
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term"enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as aMobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. TheRANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. |
|
| |
| RFC 5721 | POP3 Support for UTF-8 |
| |
| Authors: | R. Gellens, C. Newman. |
| Date: | February 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6856 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5721 |
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. |
|
| |
| RFC 5722 | Handling of Overlapping IPv6 Fragments |
| |
|
|
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. |
|
| |
| RFC 5723 | Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption |
| |
| Authors: | Y. Sheffer, H. Tschofenig. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5723 |
|
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved.In remote access situations, the Extensible Authentication Protocol(EAP) is used for authentication, which adds several more round trips and consequently latency.
To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as aVPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume anIKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. |
|
| |
| RFC 5724 | URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) |
| |
| Authors: | E. Wilde, A. Vaha-Sipila. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5724 |
|
This memo specifies the Uniform Resource Identifier (URI) scheme"sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. |
|
| |
| RFC 5725 | Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) |
| |
| Authors: | A. Begen, D. Hsu, M. Lague. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5725 |
|
This document defines a new report block type within the framework ofRTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE)Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied.By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the SessionDescription Protocol (SDP). |
|
| |
| RFC 5726 | Mobile IPv6 Location Privacy Solutions |
| |
| Authors: | Y. Qiu, F. Zhao, Ed., R. Koodli. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5726 |
|
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the MobileIPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP MobilityOptimizations (MobOpts) Research Group. |
|
| |
| RFC 5727 | Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area |
| |
|
|
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC3427. |
|
| |
| RFC 5728 | The SatLabs Group DVB-RCS MIB |
| |
| Authors: | S. Combes, P. Amundsen, M. Lambert, H-P. Lexow. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5728 |
|
This document describes the MIB module for the Digital VideoBroadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. |
|
| |
| RFC 5729 | Clarifications on the Routing of Diameter Requests Based on the Username and the Realm |
| |
| Authors: | J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou. |
| Date: | December 2009 |
| Formats: | txt json html |
| Updates: | RFC 3588 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5729 |
|
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains aNetwork Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. |
|
| |
| RFC 5730 | Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. |
|
| |
| RFC 5731 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 4931. |
|
| |
| RFC 5732 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 4932. |
|
| |
| RFC 5733 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. |
|
| |
| RFC 5734 | Extensible Provisioning Protocol (EPP) Transport over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 4934. |
|
| |
| RFC 5735 | Special Use IPv4 Addresses |
| |
|
|
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by theInternet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the RegionalInternet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional InternetRegistries. It also does not address allocations or assignments ofIPv6 addresses or autonomous system numbers. |
|
| |
| RFC 5736 | IANA IPv4 Special Purpose Address Registry |
| |
| Authors: | G. Huston, M. Cotton, L. Vegoda. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6890 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5736 |
|
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. |
|
| |
| RFC 5737 | IPv4 Address Blocks Reserved for Documentation |
| |
| Authors: | J. Arkko, M. Cotton, L. Vegoda. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updates: | RFC 1166 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5737 |
|
Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. |
|
| |
| RFC 5738 | IMAP Support for UTF-8 |
| |
|
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. |
|
| |
| RFC 5739 | IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | P. Eronen, J. Laganier, C. Madson. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5739 |
|
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes forIKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway"virtual link". |
|
| |
| RFC 5740 | NACK-Oriented Reliable Multicast (NORM) Transport Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2009 |
| Formats: | txt html json |
| Obsoletes: | RFC 3940 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5740 |
|
This document describes the messages and procedures of the Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol(TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity(possibly a unicast return path) between the senders and receivers.The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETFReliable Multicast Transport (RMT) building blocks in its design.This document obsoletes RFC 3940. |
|
| |
| RFC 5741 | RFC Streams, Headers, and Boilerplates |
| |
|
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. |
|
| |
| RFC 5742 | IESG Procedures for Handling of Independent and IRTF Stream Submissions |
| |
|
|
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the IndependentSubmission and IRTF streams.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 5743 | Definition of an Internet Research Task Force (IRTF) Document Stream |
| |
| Authors: | A. Falk. |
| Date: | December 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5743 |
|
This memo defines the publication stream for RFCs from the InternetResearch Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. |
|
| |
| RFC 5744 | Procedures for Rights Handling in the RFC Independent Submission Stream |
| |
|
|
This document specifies the procedures by which authors of RFCIndependent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the"outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. |
|
| |
| RFC 5745 | Procedures for Rights Handling in the RFC IAB Stream |
| |
| Authors: | A. Malis, Ed., IAB. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5745 |
|
|
|
| |
| RFC 5746 | Transport Layer Security (TLS) Renegotiation Indication Extension |
| |
|
|
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. |
|
| |
| RFC 5747 | 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions |
| |
| Authors: | J. Wu, Y. Cui, X. Li, M. Xu, C. Metz. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5747 |
|
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. |
|
| |
| RFC 5748 | IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5748 |
|
This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) inMultimedia Internet KEYing (MIKEY). |
|
| |
| RFC 5749 | Distribution of EAP-Based Keys for Handover and Re-Authentication |
| |
| Authors: | K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed.. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5749 |
|
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an ExtendedMaster Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication,Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. |
|
| |
| RFC 5750 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling |
| |
|
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.S/MIME agents validate certificates as described in RFC 5280, theInternet X.509 Public Key Infrastructure Certificate and CRL Profile.S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletesRFC 3850. |
|
| |
| RFC 5751 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification |
| |
|
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. |
|
| |
| RFC 5752 | Multiple Signatures in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Turner, J. Schaad. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5752 |
|
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than oneSignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. |
|
| |
| RFC 5753 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC3370 and RFC 3565 for key wrap and content encryption, NIST FIPS180-3 for message digest, SEC1 for key derivation, and RFC 2104 andRFC 4231 for message authentication code standards. This document obsoletes RFC 3278. |
|
| |
| RFC 5754 | Using SHA2 Algorithms with Cryptographic Message Syntax |
| |
|
|
This document describes the conventions for using the Secure HashAlgorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. |
|
| |
| RFC 5755 | An Internet Attribute Certificate Profile for Authorization |
| |
| Authors: | S. Farrell, R. Housley, S. Turner. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 3281 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5755 |
|
This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. |
|
| |
| RFC 5756 | Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters |
| |
| Authors: | S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. |
| Date: | January 2010 |
| Formats: | txt json html |
| Updates: | RFC 4055 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5756 |
|
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding(RSAES-OAEP) key transport algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. |
|
| |
| RFC 5757 | Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey |
| |
| Authors: | T. Schmidt, M. Waehlisch, G. Fairhurst. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5757 |
|
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast andSource-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized.Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. |
|
| |
| RFC 5758 | Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA |
| |
| Authors: | Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updates: | RFC 3279 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5758 |
|
This document updates RFC 3279 to specify algorithm identifiers andASN.1 encoding rules for the Digital Signature Algorithm (DSA) andElliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 PublicKey infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the InternetX.509 PKI. |
|
| |
| RFC 5759 | Suite B Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | J. Solinas, L. Zieglar. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5759 |
|
This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 PublicKey Infrastructure Certificate and Certificate Revocation List (CRL)Profile". |
|
| |
| RFC 5760 | RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback |
| |
| Authors: | J. Ott, J. Chesterfield, E. Schooler. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6128 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5760 |
|
This document specifies an extension to the Real-time TransportControl Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. |
|
| |
| RFC 5761 | Multiplexing RTP Data and Control Packets on a Single Port |
| |
|
|
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the SessionDescription Protocol (SDP) can be used to signal multiplexed sessions. |
|
| |
| RFC 5762 | RTP and the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion ControlProtocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. |
|
| |
| RFC 5763 | Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) |
| |
| Authors: | J. Fischl, H. Tschofenig, E. Rescorla. |
| Date: | May 2010 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5763 |
|
This document specifies how to use the Session Initiation Protocol(SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. |
|
| |
| RFC 5764 | Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) |
| |
|
|
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTPControl Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. |
|
| |
| RFC 5765 | Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications |
| |
| Authors: | H. Schulzrinne, E. Marocco, E. Ivov. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5765 |
|
Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2PResearch Group. |
|
| |
| RFC 5766 | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts(peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (TraversalUsing Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The TURN protocol was designed to be used as part of the ICE(Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. |
|
| |
| RFC 5767 | User-Agent-Driven Privacy Mechanism for SIP |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5767 |
|
This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) andTraversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. |
|
| |
| RFC 5768 | Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5768 |
|
This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. |
|
| |
| RFC 5769 | Test Vectors for Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | R. Denis-Courmont. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5769 |
|
The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these --FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. |
|
| |
| RFC 5770 | Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators |
| |
| Authors: | M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed.. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5770 |
|
This document specifies extensions to the Host Identity Protocol(HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive ConnectivityEstablishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulatingEncapsulating Security Payload (ESP) packets within the User DatagramProtocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.With these extensions HIP is able to work in environments that haveNATs and provides a generic NAT traversal solution to higher-layer networking applications. |
|
| |
| RFC 5771 | IANA Guidelines for IPv4 Multicast Address Assignments |
| |
|
|
This document provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. It obsoletesRFC 3171 and RFC 3138 and updates RFC 2780. |
|
| |
| RFC 5772 | A Set of Possible Requirements for a Future Routing Architecture |
| |
| Authors: | A. Doria, E. Davies, F. Kastenholz. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5772 |
|
The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group(RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for theInternet in the future.
The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. |
|
| |
| RFC 5773 | Analysis of Inter-Domain Routing Requirements and History |
| |
| Authors: | E. Davies, A. Doria. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5773 |
|
This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to"A Set of Possible Requirements for a Future Routing Architecture"(RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. |
|
| |
| RFC 5774 | Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition |
| |
|
|
This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. |
|
| |
| RFC 5775 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, M. Watson, L. Vicisano. |
| Date: | April 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 3450 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5775 |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. |
|
| |
| RFC 5776 | Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca, A. Francillon, S. Faurite. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5776 |
|
This document details the Timed Efficient Stream Loss-TolerantAuthentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within theAsynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. |
|
| |
| RFC 5777 | Traffic Classification and Quality of Service (QoS) Attributes for Diameter |
| |
| Authors: | J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5777 |
|
This document defines a number of Diameter attribute-value pairs(AVPs) for traffic classification with actions for filtering andQuality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by theAugmented Backus-Naur Form (ABNF) specification of the respectiveDiameter command extension policy. |
|
| |
| RFC 5778 | Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction |
| |
| Authors: | J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5778 |
|
Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and theDiameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and aDiameter server.
This document defines the home agent to the Diameter server communication when the mobile node authenticates using the InternetKey Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. |
|
| |
| RFC 5779 | Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server |
| |
| Authors: | J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5779 |
|
This specification defines Authentication, Authorization, andAccounting (AAA) interactions between Proxy Mobile IPv6 entities(both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. |
|
| |
| RFC 5780 | NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) |
| |
|
|
This specification defines an experimental usage of the SessionTraversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. |
|
| |
| RFC 5781 | The rsync URI Scheme |
| |
| Authors: | S. Weiler, D. Ward, R. Housley. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5781 |
|
This document specifies the rsync Uniform Resource Identifier (URI) scheme. |
|
| |
| RFC 5782 | DNS Blacklists and Whitelists |
| |
| Authors: | J. Levine. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5782 |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. |
|
| |
| RFC 5783 | Congestion Control in the RFC Series |
| |
| Authors: | M. Welzl, W. Eddy. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5783 |
|
This document is an informational snapshot taken by the IRTF'sInternet Congestion Control Research Group (ICCRG) in October 2008.It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. |
|
| |
| RFC 5784 | Sieve Email Filtering: Sieves and Display Directives in XML |
| |
| Authors: | N. Freed, S. Vedam. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5784 |
|
This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.
The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. |
|
| |
| RFC 5785 | Defining Well-Known Uniform Resource Identifiers (URIs) |
| |
|
|
This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes. |
|
| |
| RFC 5786 | Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions |
| |
|
|
OSPF Traffic Engineering (TE) extensions are used to advertise TELink State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID.
In order to allow other routers in a network to compute MultiprotocolLabel Switching (MPLS) Traffic Engineered Label Switched Paths (TELSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.
This document describes procedures that enhance OSPF TE to advertise a router's local addresses. |
|
| |
| RFC 5787 | OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing |
| |
|
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. |
|
| |
| RFC 5788 | IMAP4 Keyword Registry |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5788 |
|
The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. |
|
| |
| RFC 5789 | PATCH Method for HTTP |
| |
| Authors: | L. Dusseault, J. Snell. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5789 |
|
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existingHTTP PUT method only allows a complete replacement of a document.This proposal adds a new HTTP method, PATCH, to modify an existingHTTP resource. |
|
| |
| RFC 5790 | Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols |
| |
| Authors: | H. Liu, W. Cao, H. Asaeda. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5790 |
|
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-IGMPv3 and LW-MLDv2), which simplify the standard (full) versions ofIGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. |
|
| |
| RFC 5791 | RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete |
| |
|
|
This document obsoletes RFC 2731, "Encoding Dublin Core Metadata inHTML", as further development of this specification has moved to theDublin Core Metadata Initiative (DCMI). |
|
| |
| RFC 5792 | PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) |
| |
| Authors: | P. Sangster, K. Narayan. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5792 |
|
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. |
|
| |
| RFC 5793 | PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) |
| |
| Authors: | R. Sahita, S. Hanna, R. Hurst, K. Narayan. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5793 |
|
This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEARequirements specification. |
|
| |
| RFC 5794 | A Description of the ARIA Encryption Algorithm |
| |
| Authors: | J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5794 |
|
This document describes the ARIA encryption algorithm. ARIA is a128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. |
|
| |
| RFC 5795 | The RObust Header Compression (ROHC) Framework |
| |
| Authors: | K. Sandlund, G. Pelletier, L-E. Jonsson. |
| Date: | March 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 4995 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5795 |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. |
|
| |
| RFC 5796 | Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages |
| |
| Authors: | W. Atwood, S. Islam, M. Siami. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updates: | RFC 4601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5796 |
|
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - SparseMode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security(IPsec) Encapsulating Security Payload (ESP) or (optionally) theAuthentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. |
|
| |
| RFC 5797 | FTP Command and Extension Registry |
| |
|
|
Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command andFeature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. |
|
| |
| RFC 5798 | Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
| |
|
|
This memo defines the Virtual Router Redundancy Protocol (VRRP) forIPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in"Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to theseIPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. ForIPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6Neighbor Discovery mechanisms. |
|
