RFC Abstracts
RFC5620 - RFC Editor Model (Version 1)
The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.
RFC5619 - Softwire Security Analysis and Requirements
This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]
RFC5618 - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]
RFC5617 - DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]
RFC5616 - Streaming Internet Messaging Attachments
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
RFC5615 - H.248/MEGACO Registration Procedures
This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5614 - Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.
RFC5613 - OSPF Link-Local Signaling
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.
RFC5612 - Enterprise Number for Documentation Use
This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.
RFC5611 - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires
This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]
RFC5610 - Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements
This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]
RFC5609 - State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.
RFC5608 - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]
RFC5607 - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]
RFC5606 - Implications of 'retransmission-allowed' for SIP Location Conveyance
This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
RFC5605 - Managed Objects for ATM over Packet Switched Networks (PSNs)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]
RFC5604 - Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]
RFC5603 - Ethernet Pseudowire (PW) Management Information Base (MIB)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]
RFC5602 - Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]
RFC5601 - Pseudowire (PW) Management Information Base (MIB)
This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]
RFC5598 - Internet Mail Architecture
Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.
RFC5597 - Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5596 - Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]
RFC5595 - The Datagram Congestion Control Protocol (DCCP) Service Codes
This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]
RFC5594 - Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.
RFC5593 - Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.
RFC5592 - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
RFC5591 - Transport Security Model for the Simple Network Management Protocol (SNMP)
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).
RFC5590 - Transport Subsystem for the Simple Network Management Protocol (SNMP)
This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]
RFC5589 - Session Initiation Protocol (SIP) Call Control - Transfer
This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5588 - Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials
This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]
RFC5587 - Extended Generic Security Service Mechanism Inquiry APIs
This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.
RFC5586 - MPLS Generic Associated Channel
This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.
RFC5585 - DomainKeys Identified Mail (DKIM) Service Overview
This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.
RFC5584 - RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]
RFC5583 - Signaling Media Decoding Dependency in the Session Description Protocol (SDP)
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
RFC5582 - Location-to-URL Mapping Architecture and Framework
This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.
RFC5581 - The Camellia Cipher in OpenPGP
This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.
RFC5580 - Carrying Location Objects in RADIUS and Diameter
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.
RFC5579 - Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5578 - PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5577 - RTP Payload Format for ITU-T Recommendation G.722.1
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]
RFC5576 - Source-Specific Media Attributes in the Session Description Protocol (SDP)
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]
RFC5575 - Dissemination of Flow Specification Rules
This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
RFC5574 - RTP Payload Format for the Speex Codec
Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]
RFC5573 - Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.
RFC5572 - IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.
RFC5571 - Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]
RFC5570 - Common Architecture Label IPv6 Security Option (CALIPSO)
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.
RFC5569 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.
The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.
RFC5619 - Softwire Security Analysis and Requirements
This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]
RFC5618 - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]
RFC5617 - DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]
RFC5616 - Streaming Internet Messaging Attachments
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
RFC5615 - H.248/MEGACO Registration Procedures
This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5614 - Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.
RFC5613 - OSPF Link-Local Signaling
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.
RFC5612 - Enterprise Number for Documentation Use
This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.
RFC5611 - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires
This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]
RFC5610 - Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements
This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]
RFC5609 - State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.
RFC5608 - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]
RFC5607 - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]
RFC5606 - Implications of 'retransmission-allowed' for SIP Location Conveyance
This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
RFC5605 - Managed Objects for ATM over Packet Switched Networks (PSNs)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]
RFC5604 - Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]
RFC5603 - Ethernet Pseudowire (PW) Management Information Base (MIB)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]
RFC5602 - Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]
RFC5601 - Pseudowire (PW) Management Information Base (MIB)
This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]
RFC5598 - Internet Mail Architecture
Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.
RFC5597 - Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5596 - Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]
RFC5595 - The Datagram Congestion Control Protocol (DCCP) Service Codes
This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]
RFC5594 - Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.
RFC5593 - Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.
RFC5592 - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
RFC5591 - Transport Security Model for the Simple Network Management Protocol (SNMP)
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).
RFC5590 - Transport Subsystem for the Simple Network Management Protocol (SNMP)
This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]
RFC5589 - Session Initiation Protocol (SIP) Call Control - Transfer
This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5588 - Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials
This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]
RFC5587 - Extended Generic Security Service Mechanism Inquiry APIs
This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.
RFC5586 - MPLS Generic Associated Channel
This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.
RFC5585 - DomainKeys Identified Mail (DKIM) Service Overview
This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.
RFC5584 - RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]
RFC5583 - Signaling Media Decoding Dependency in the Session Description Protocol (SDP)
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
RFC5582 - Location-to-URL Mapping Architecture and Framework
This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.
RFC5581 - The Camellia Cipher in OpenPGP
This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.
RFC5580 - Carrying Location Objects in RADIUS and Diameter
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.
RFC5579 - Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5578 - PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5577 - RTP Payload Format for ITU-T Recommendation G.722.1
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]
RFC5576 - Source-Specific Media Attributes in the Session Description Protocol (SDP)
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]
RFC5575 - Dissemination of Flow Specification Rules
This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
RFC5574 - RTP Payload Format for the Speex Codec
Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]
RFC5573 - Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.
RFC5572 - IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.
RFC5571 - Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]
RFC5570 - Common Architecture Label IPv6 Security Option (CALIPSO)
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.
RFC5569 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.