| |
| RFC 5401 | Multicast Negative-Acknowledgment (NACK) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5401 |
|
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. |
|
| |
| RFC 5402 | Compressed Data within an Internet Electronic Data Interchange (EDI) Message |
| |
| Authors: | T. Harding, Ed.. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5402 |
|
This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic DataInterchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. |
|
| |
| RFC 5403 | RPCSEC_GSS Version 2 |
| |
|
|
This document describes version 2 of the RPCSEC_GSS protocol.Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic SecurityServices Application Programming Interface (GSS-API). |
|
| |
| RFC 5404 | RTP Payload Format for G.719 |
| |
| Authors: | M. Westerlund, I. Johansson. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5404 |
|
This document specifies the payload format for packetization of theG.719 full-band codec encoded audio signals into the Real-timeTransport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. |
|
| |
| RFC 5405 | Unicast UDP Usage Guidelines for Application Designers |
| |
| Authors: | L. Eggert, G. Fairhurst. |
| Date: | November 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8085 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5405 |
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.Because congestion control is critical to the stable operation of theInternet, applications and upper-layer protocols that choose to useUDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use ofUDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. |
|
| |
| RFC 5406 | Guidelines for Specifying the Use of IPsec Version 2 |
| |
|
|
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. |
|
| |
| RFC 5407 | Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) |
| |
| Authors: | M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. |
| Date: | December 2008 |
| Formats: | txt json html |
| Also: | BCP 0147 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5407 |
|
This document gives example call flows of race conditions in theSession Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows includeSIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. |
|
| |
| RFC 5408 | Identity-Based Encryption Architecture and Supporting Data Structures |
| |
| Authors: | G. Appenzeller, L. Martin, M. Schertler. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5408 |
|
This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. |
|
| |
| RFC 5409 | Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) |
| |
| Authors: | L. Martin, M. Schertler. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5409 |
|
This document describes the conventions for using the Boneh-Franklin(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. |
|
| |
| RFC 5410 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 |
| |
|
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload to transport the short-term key message(STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 5411 | A Hitchhiker's Guide to the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5411 |
|
The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. |
|
| |
| RFC 5412 | Lightweight Access Point Protocol |
| |
| Authors: | P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5412 |
|
In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.
The IETF's CAPWAP (Control and Provisioning of Wireless AccessPoints) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and WirelessTermination Points (the latter are also commonly referred to asLightweight Access Points). This specification defines theLightweight Access Point Protocol (LWAPP), which addresses theCAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. |
|
| |
| RFC 5413 | SLAPP: Secure Light Access Point Protocol |
| |
| Authors: | P. Narasimhan, D. Harkins, S. Ponnuswamy. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5413 |
|
The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and AccessControllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.
In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.
Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). |
|
| |
| RFC 5414 | Wireless LAN Control Protocol (WiCoP) |
| |
| Authors: | S. Iino, S. Govindan, M. Sugiura, H. Cheng. |
| Date: | February 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5415 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5414 |
|
The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of WirelessAccess Points (CAPWAP). |
|
| |
| RFC 5415 | Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification |
| |
|
|
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. |
|
| |
| RFC 5416 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 |
| |
| Authors: | P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5416 |
|
Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralizedAccess Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. |
|
| |
| RFC 5417 | Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option |
| |
| Authors: | P. Calhoun. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5417 |
|
The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover theAccess Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. |
|
| |
| RFC 5418 | Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments |
| |
| Authors: | S. Kelly, T. Clancy. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5418 |
|
Early Wireless Local Area Network (WLAN) deployments feature a "fat"Access Point (AP), which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control andProvisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. |
|
| |
| RFC 5419 | Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) |
| |
| Authors: | B. Patil, G. Dommety. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5419 |
|
Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update(BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in MobileIPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. |
|
| |
| RFC 5420 | Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs.
This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. |
|
| |
| RFC 5421 | Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) |
| |
| Authors: | N. Cam-Winget, H. Zhou. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5421 |
|
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic TokenCard method (EAP-GTC), may be executed to authenticate the peer. |
|
| |
| RFC 5422 | Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) |
| |
| Authors: | N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5422 |
|
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use ofEAP-FAST for dynamic provisioning. |
|
| |
| RFC 5423 | Internet Message Store Events |
| |
| Authors: | R. Gellens, C. Newman. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5423 |
|
One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.
This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. |
|
| |
| RFC 5424 | The Syslog Protocol |
| |
|
|
This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.
This document obsoletes RFC 3164. |
|
| |
| RFC 5425 | Transport Layer Security (TLS) Transport Mapping for Syslog |
| |
| Authors: | F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. |
| Date: | March 2009 |
| Formats: | txt html json |
| Updated by: | RFC 9662 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5425 |
|
This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.This document describes the security threats to syslog and how TLS can be used to counter such threats. |
|
| |
| RFC 5426 | Transmission of Syslog Messages over UDP |
| |
| Authors: | A. Okmianski. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5426 |
|
This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. |
|
| |
| RFC 5427 | Textual Conventions for Syslog Management |
| |
| Authors: | G. Keeni. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5427 |
|
This MIB module defines textual conventions to represent Facility andSeverity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. |
|
| |
| RFC 5428 | Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | S. Channabasappa, W. De Ketelaere, E. Nechamkin. |
| Date: | April 2009 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5428 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant MultimediaTerminal Adapter devices. |
|
| |
| RFC 5429 | Sieve Email Filtering: Reject and Extended Reject Extensions |
| |
|
|
This memo updates the definition of the Sieve mail filtering language"reject" extension, originally defined in RFC 3028.
A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces,Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the"ereject" action to require messages to be refused during the SMTP transaction, if possible.
The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. |
|
| |
| RFC 5430 | Suite B Profile for Transport Layer Security (TLS) |
| |
| Authors: | M. Salter, E. Rescorla, R. Housley. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6460 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5430 |
|
The United States government has published guidelines for "NSA SuiteB Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. |
|
| |
| RFC 5431 | Diameter ITU-T Rw Policy Enforcement Interface Application |
| |
| Authors: | D. Sun. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5431 |
|
This document describes the need for a new pair of IANA DiameterCommand Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union -Telecommunication Standardization Sector (ITU-T). |
|
| |
| RFC 5432 | Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) |
| |
| Authors: | J. Polk, S. Dhesikan, G. Camarillo. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5432 |
|
The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on theInternet, there is more than one QoS service available.Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. |
|
| |
| RFC 5433 | Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method |
| |
| Authors: | T. Clancy, H. Tschofenig. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5433 |
|
This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. |
|
| |
| RFC 5434 | Considerations for Having a Successful Birds-of-a-Feather (BOF) Session |
| |
| Authors: | T. Narten. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5434 |
|
This document discusses tactics and strategy for hosting a successfulIETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. |
|
| |
| RFC 5435 | Sieve Email Filtering: Extension for Notifications |
| |
| Authors: | A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. |
| Date: | January 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5435 |
|
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol(XMPP), or Global System for Mobile Communications (GSM) ShortMessage Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. |
|
| |
| RFC 5436 | Sieve Notification Mechanism: mailto |
| |
|
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. |
|
| |
| RFC 5437 | Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, A. Melnikov. |
| Date: | January 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5437 |
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the ExtensibleMessaging and Presence Protocol (XMPP), also known as Jabber. |
|
| |
| RFC 5438 | Instant Message Disposition Notification (IMDN) |
| |
| Authors: | E. Burger, H. Khartabil. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5438 |
|
Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications(IMDN), including delivery, processing, and display notifications, for page-mode instant messages.
The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
This document also describes how SIP entities behave using this extension. |
|
| |
| RFC 5439 | An Analysis of Scaling Issues in MPLS-TE Core Networks |
| |
| Authors: | S. Yasukawa, A. Farrel, O. Komolafe. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5439 |
|
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.
This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.
This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipointMPLS-TE LSPs are for future study. |
|
| |
| RFC 5440 | Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
|
|
This document specifies the Path Computation Element (PCE)Communication Protocol (PCEP) for communications between a PathComputation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. |
|
| |
| RFC 5441 | A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths |
| |
| Authors: | JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5441 |
|
The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. |
|
| |
| RFC 5442 | LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail |
| |
| Authors: | E. Burger, G. Parsons. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5442 |
|
This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email toSupport Diverse Service Environments) working group in the IETF.This document also describes how the LEMONADE architecture meetsOMA's requirements for their Mobile Email (MEM) service. |
|
| |
| RFC 5443 | LDP IGP Synchronization |
| |
| Authors: | M. Jork, A. Atlas, L. Fang. |
| Date: | March 2009 |
| Formats: | txt html json |
| Updated by: | RFC 6138 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5443 |
|
In certain networks, there is dependency on the edge-to-edge LabelSwitched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS)Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol(IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border GatewayProtocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. |
|
| |
| RFC 5444 | Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format |
| |
|
|
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. |
|
| |
| RFC 5445 | Basic Forward Error Correction (FEC) Schemes |
| |
|
|
This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT)FEC building block for the Compact No-Code FEC Scheme, the SmallBlock, Large Block, and Expandable FEC Scheme, the Small BlockSystematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. |
|
| |
| RFC 5446 | Service Selection for Mobile IPv4 |
| |
| Authors: | J. Korhonen, U. Nilsson. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5446 |
|
In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a ServiceSelection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. |
|
| |
| RFC 5447 | Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction |
| |
| Authors: | J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5447 |
|
A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication,Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network AccessServer to home AAA server interface. |
|
| |
| RFC 5448 | Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') |
| |
|
|
This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication ProtocolMethod for 3rd Generation Authentication and Key Agreement) method.The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd GenerationPartnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. |
|
| |
| RFC 5449 | OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks |
| |
| Authors: | E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5449 |
|
This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". |
|
| |
| RFC 5450 | Transmission Time Offsets in RTP Streams |
| |
| Authors: | D. Singer, H. Desineni. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5450 |
|
This document describes a method to inform Real-time TransportProtocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. |
|
| |
| RFC 5451 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.Any receiver-side software, such as mail filters or Mail User Agents(MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
|
| |
| RFC 5452 | Measures for Making DNS More Resilient against Forged Answers |
| |
| Authors: | A. Hubert, R. van Mook. |
| Date: | January 2009 |
| Formats: | txt html json |
| Updates: | RFC 2181 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5452 |
|
The current Internet climate poses serious threats to the Domain NameSystem. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.
By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. |
|
| |
| RFC 5453 | Reserved IPv6 Interface Identifiers |
| |
| Authors: | S. Krishnan. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5453 |
|
Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. AnIPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. |
|
| |
| RFC 5454 | Dual-Stack Mobile IPv4 |
| |
| Authors: | G. Tsirtsis, V. Park, H. Soliman. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5454 |
|
This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 andIPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. |
|
| |
| RFC 5455 | Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol |
| |
| Authors: | S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5455 |
|
This document specifies a CLASSTYPE object to support Diffserv-AwareTraffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). |
|
| |
| RFC 5456 | IAX: Inter-Asterisk eXchange Version 2 |
| |
| Authors: | M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5456 |
|
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for theAsterisk Private Branch Exchange (PBX) and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.
IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work aroundNAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. |
|
| |
| RFC 5457 | IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 |
| |
| Authors: | E. Guy, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5457 |
|
This document establishes the IANA registries for IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. |
|
| |
| RFC 5458 | Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol |
| |
| Authors: | H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5458 |
|
The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.
The analysis also describes applicability to the Generic StreamEncapsulation (GSE) defined by the Digital Video Broadcasting (DVB)Project. |
|
| |
| RFC 5459 | G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support |
| |
|
|
This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) Recommendation G.729.1 audio codec. It adds DiscontinuousTransmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. |
|
| |
| RFC 5460 | DHCPv6 Bulk Leasequery |
| |
|
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. |
|
| |
| RFC 5461 | TCP's Reaction to Soft Errors |
| |
| Authors: | F. Gont. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5461 |
|
This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. |
|
| |
| RFC 5462 | Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field |
| |
| Authors: | L. Andersson, R. Asati. |
| Date: | February 2009 |
| Formats: | txt html json |
| Updates: | RFC 3032, RFC 3270, RFC 3272, RFC 3443, RFC 3469, RFC 3564, RFC 3985, RFC 4182, RFC 4364, RFC 4379, RFC 4448, RFC 4761, RFC 5129 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5462 |
|
The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".
Although the intended use of the EXP field was as a "Class ofService" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.
To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. |
|
| |
| RFC 5463 | Sieve Email Filtering: Ihave Extension |
| |
| Authors: | N. Freed. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5463 |
|
This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. |
|
| |
| RFC 5464 | The IMAP METADATA Extension |
| |
| Authors: | C. Daboo. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5464 |
|
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. |
|
| |
| RFC 5465 | The IMAP NOTIFY Extension |
| |
| Authors: | A. Gulbrandsen, C. King, A. Melnikov. |
| Date: | February 2009 |
| Formats: | txt json html |
| Updates: | RFC 5267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5465 |
|
This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. |
|
| |
| RFC 5466 | IMAP4 Extension for Named Searches (Filters) |
| |
| Authors: | A. Melnikov, C. King. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5466 |
|
The document defines a way to persistently store named IMAP (RFC3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. |
|
| |
| RFC 5467 | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6387 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5467 |
|
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. |
|
| |
| RFC 5468 | Performance Analysis of Inter-Domain Path Computation Methodologies |
| |
| Authors: | S. Dasgupta, J. de Oliveira, JP. Vasseur. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5468 |
|
This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE)Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. |
|
| |
| RFC 5469 | DES and IDEA Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES(when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. |
|
| |
| RFC 5470 | Architecture for IP Flow Information Export |
| |
| Authors: | G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6183 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5470 |
|
This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. |
|
| |
| RFC 5471 | Guidelines for IP Flow Information Export (IPFIX) Testing |
| |
| Authors: | C. Schmoll, P. Aitken, B. Claise. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5471 |
|
This document presents a list of tests for implementers of IP FlowInformation eXport (IPFIX) compliant Exporting Processes andCollecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process andCollecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. |
|
| |
| RFC 5472 | IP Flow Information Export (IPFIX) Applicability |
| |
| Authors: | T. Zseby, E. Boschi, N. Brownlee, B. Claise. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5472 |
|
In this document, we describe the applicability of the IP FlowInformation eXport (IPFIX) protocol for a variety of applications.We show how applications can use IPFIX, describe the relevantInformation Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. |
|
| |
| RFC 5473 | Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports |
| |
| Authors: | E. Boschi, L. Mark, B. Claise. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5473 |
|
This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.
This method works by separating information common to several FlowRecords from information specific to an individual Flow Record.Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. |
|
| |
| RFC 5474 | A Framework for Packet Selection and Reporting |
| |
| Authors: | N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5474 |
|
This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of thePSAMP functions. |
|
| |
| RFC 5475 | Sampling and Filtering Techniques for IP Packet Selection |
| |
| Authors: | T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5475 |
|
This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. |
|
| |
| RFC 5476 | Packet Sampling (PSAMP) Protocol Specifications |
| |
| Authors: | B. Claise, Ed., A. Johnson, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5476 |
|
This document specifies the export of packet information from aPacket SAMPling (PSAMP) Exporting Process to a PSAMP CollectingProcess. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how theIPFIX protocol is used for PSAMP export of packet information. |
|
| |
| RFC 5477 | Information Model for Packet Sampling Exports |
| |
| Authors: | T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5477 |
|
This memo defines an information model for the Packet SAMPling(PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.As the PSAMP protocol is based on the IP Flow Information eXport(IPFIX) protocol, this information model is an extension to the IPFIX information model. |
|
| |
| RFC 5478 | IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces |
| |
| Authors: | J. Polk. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5478 |
|
This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the USDefense Information Systems Agency, and places these namespaces in the IANA registry. |
|
| |
| RFC 5479 | Requirements and Analysis of Media Security Management Protocols |
| |
| Authors: | D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5479 |
|
This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. |
|
| |
| RFC 5480 | Elliptic Curve Cryptography Subject Public Key Information |
| |
| Authors: | S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updates: | RFC 3279 |
| Updated by: | RFC 8813 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5480 |
|
This document specifies the syntax and semantics for the SubjectPublic Key Information field in certificates that support EllipticCurve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile", RFC 3279. |
|
| |
| RFC 5481 | Packet Delay Variation Applicability Statement |
| |
| Authors: | A. Morton, B. Claise. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5481 |
|
Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. |
|
| |
| RFC 5482 | TCP User Timeout Option |
| |
| Authors: | L. Eggert, F. Gont. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5482 |
|
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. |
|
| |
| RFC 5483 | ENUM Implementation Issues and Experiences |
| |
| Authors: | L. Conroy, K. Fujiwara. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5483 |
|
This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic DelegationDiscovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. |
|
| |
| RFC 5484 | Associating Time-Codes with RTP Streams |
| |
| Authors: | D. Singer. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5484 |
|
This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers(SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. |
|
| |
| RFC 5485 | Digital Signatures on Internet-Draft Documents |
| |
|
|
This document specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. |
|
| |
| RFC 5486 | Session Peering for Multimedia Interconnect (SPEERMINT) Terminology |
| |
| Authors: | D. Malas, Ed., D. Meyer, Ed.. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5486 |
|
This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). |
|
| |
| RFC 5487 | Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode |
| |
| Authors: | M. Badra. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5487 |
|
RFC 4279 and RFC 4785 describe pre-shared key cipher suites forTransport Layer Security (TLS). However, all those cipher suites useSHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) inGalois Counter Mode (GCM). |
|
| |
| RFC 5488 | Network Mobility (NEMO) Management Information Base |
| |
| Authors: | S. Gundavelli, G. Keeni, K. Koide, K. Nagami. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5488 |
|
This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, theNEMO MIB will be used to monitor and control a Mobile IPv6 node withNEMO functionality. |
|
| |
| RFC 5489 | ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | M. Badra, I. Hajjeh. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5489 |
|
This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy(PFS). |
|
| |
| RFC 5490 | The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata |
| |
| Authors: | A. Melnikov. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5490 |
|
This memo defines an extension to the Sieve mail filtering language(RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. |
|
| |
| RFC 5491 | GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations |
| |
|
|
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented.In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. |
|
| |
| RFC 5492 | Capabilities Advertisement with BGP-4 |
| |
|
|
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 3392. |
|
| |
| RFC 5493 | Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network |
| |
| Authors: | D. Caviglia, D. Bramanti, D. Li, D. McDysan. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5493 |
|
From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.
This memo sets out the requirements for such procedures within aGeneralized Multiprotocol Label Switching (GMPLS) network. |
|
| |
| RFC 5494 | IANA Allocation Guidelines for the Address Resolution Protocol (ARP) |
| |
| Authors: | J. Arkko, C. Pignataro. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updates: | RFC 0826, RFC 0951, RFC 1044, RFC 1329, RFC 2131, RFC 2132, RFC 2176, RFC 2225, RFC 2834, RFC 2835, RFC 3315, RFC 4338, RFC 4361, RFC 4701 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5494 |
|
This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. |
|
| |
| RFC 5495 | Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures |
| |
| Authors: | D. Li, J. Gao, A. Satyanarayana, S. Bardalai. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5495 |
|
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in aMultiprotocol Label Switching (MPLS) traffic-engineered (TE) network.The Hello message has been extended for use in Generalized MPLS(GMPLS) networks for state recovery of control channel or nodal faults.
The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a LabelSwitched Path (LSP).
Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchangingRSVP messages with its upstream and downstream neighbors.
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. |
|
| |
| RFC 5496 | The Reverse Path Forwarding (RPF) Vector TLV |
| |
| Authors: | IJ. Wijnands, A. Boers, E. Rosen. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5496 |
|
This document describes a use of the Protocol Independent Multicast(PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. |
|
| |
| RFC 5497 | Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | T. Clausen, C. Dearlove. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5497 |
|
This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address BlockTLVs for representing validity and interval times for MANET routing protocols. |
|
| |
| RFC 5498 | IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols |
| |
| Authors: | I. Chakeres. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5498 |
|
This document enumerates several common IANA allocations for use byMobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. |
|
