Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 5700 - 5799s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 5701 IPv6 Address Specific BGP Extended Community Attribute
 
Authors:Y. Rekhter.
Date:November 2009
Formats:txt pdf
Updated by:RFC 7153, RFC 7606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5701
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
 
Authors:J. Jansen.
Date:October 2009
Formats:txt pdf
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5702
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 pdf
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 pdf
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)
 
Authors:E. Rescorla.
Date:March 2010
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5705
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:D. Romascanu, H. Tschofenig.
Date:January 2010
Formats:txt pdf
Obsoleted by:RFC 6733
Updates:RFC 3588
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5719
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 pdf
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 pdf
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
 
Authors:S. Krishnan.
Date:December 2009
Formats:txt pdf
Updates:RFC 2460
Updated by:RFC 6946
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5722
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Peterson, C. Jennings, R. Sparks.
Date:March 2010
Formats:txt pdf
Obsoletes:RFC 3427
Updates:RFC 3265, RFC 3969
Updated by:RFC 7957
Also:BCP 0067
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5727
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 pdf
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 pdf
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)
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt pdf
Obsoletes:RFC 4930
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5730
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
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt pdf
Obsoletes:RFC 4931
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5731
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
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt pdf
Obsoletes:RFC 4932
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5732
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
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt pdf
Obsoletes:RFC 4933
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5733
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
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt pdf
Obsoletes:RFC 4934
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5734
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
 
Authors:M. Cotton, L. Vegoda.
Date:January 2010
Formats:txt pdf
Obsoletes:RFC 3330
Obsoleted by:RFC 6890
Updated by:RFC 6598
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5735
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 pdf
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 pdf
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
 
Authors:P. Resnick, C. Newman.
Date:March 2010
Formats:txt pdf
Obsoleted by:RFC 6855
Updates:RFC 3501
Status:EXPERIMENTAL
DOI:10.17487/RFC 5738
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 pdf
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 pdf
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
 
Authors:L. Daigle, Ed., O. Kolkman, Ed., IAB.
Date:December 2009
Formats:txt pdf
Obsoleted by:RFC 7841
Updates:RFC 2223, RFC 4844
Status:INFORMATIONAL
DOI:10.17487/RFC 5741
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
 
Authors:H. Alvestrand, R. Housley.
Date:December 2009
Formats:txt pdf
Obsoletes:RFC 3932
Updates:RFC 2026, RFC 3710
Also:BCP 0092
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5742
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 pdf
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
 
Authors:R. Braden, J. Halpern.
Date:December 2009
Formats:txt pdf
Updates:RFC 4846
Status:INFORMATIONAL
DOI:10.17487/RFC 5744
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 pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 5745
 
 
RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension
 
Authors:E. Rescorla, M. Ray, S. Dispensa, N. Oskov.
Date:February 2010
Formats:txt pdf
Updates:RFC 5246, RFC 4366, RFC 4347, RFC 4346, RFC 2246
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5746
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 pdf
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 pdf
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 pdf
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
 
Authors:B. Ramsdell, S. Turner.
Date:January 2010
Formats:txt pdf
Obsoletes:RFC 3850
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5750
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
 
Authors:B. Ramsdell, S. Turner.
Date:January 2010
Formats:txt pdf
Obsoletes:RFC 3851
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5751
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 pdf
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)
 
Authors:S. Turner, D. Brown.
Date:January 2010
Formats:txt pdf
Obsoletes:RFC 3278
Status:INFORMATIONAL
DOI:10.17487/RFC 5753
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
 
Authors:S. Turner.
Date:January 2010
Formats:txt pdf
Updates:RFC 3370
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5754
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
Status:INFORMATIONAL
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 pdf
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
 
Authors:C. Perkins, M. Westerlund.
Date:April 2010
Formats:txt pdf
Updates:RFC 3550, RFC 3551
Updated by:RFC 8035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5761
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)
 
Authors:C. Perkins.
Date:April 2010
Formats:txt pdf
Updated by:RFC 6773
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5762
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 pdf
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)
 
Authors:D. McGrew, E. Rescorla.
Date:May 2010
Formats:txt pdf
Updated by:RFC 7983
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5764
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 pdf
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)
 
Authors:R. Mahy, P. Matthews, J. Rosenberg.
Date:April 2010
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5766
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:M. Cotton, L. Vegoda, D. Meyer.
Date:March 2010
Formats:txt pdf
Obsoletes:RFC 3138, RFC 3171
Updates:RFC 2780
Also:BCP 0051
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5771
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 pdf
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 pdf
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
 
Authors:K. Wolf, A. Mayrhofer.
Date:March 2010
Formats:txt pdf
Updates:RFC 4776
Also:BCP 0154
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5774
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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)
 
Authors:D. MacDonald, B. Lowekamp.
Date:May 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5780
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 pdf
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 pdf
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 pdf
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 pdf
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)
 
Authors:M. Nottingham, E. Hammer-Lahav.
Date:April 2010
Formats:txt pdf
Updates:RFC 2616, RFC 2818
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5785
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
 
Authors:R. Aggarwal, K. Kompella.
Date:March 2010
Formats:txt pdf
Updates:RFC 3630
Updated by:RFC 6827
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5786
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
 
Authors:D. Papadimitriou.
Date:March 2010
Formats:txt pdf
Obsoleted by:RFC 6827
Status:EXPERIMENTAL
DOI:10.17487/RFC 5787
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Reschke, J. Kunze.
Date:February 2010
Formats:txt pdf
Obsoletes:RFC 2731
Status:INFORMATIONAL
DOI:10.17487/RFC 5791
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Klensin, A. Hoenes.
Date:March 2010
Formats:txt pdf
Updates:RFC 0959
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5797
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
 
Authors:S. Nadas, Ed..
Date:March 2010
Formats:txt pdf
Obsoletes:RFC 3768
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5798
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.