RFC Abstracts

RFC5841 - TCP Option to Denote Packet Mood
This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5840 - Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]
RFC5839 - An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification
The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]
RFC5838 - Support of Address Families in OSPFv3
This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]
RFC5837 - Extending ICMP for Interface and Next-Hop Identification
This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.
RFC5836 - Extensible Authentication Protocol (EAP) Early Authentication Problem Statement
Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5835 - Framework for Metric Composition
This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5834 - Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5833 - Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5832 - GOST R 34.10-2001: Digital Signature Algorithm
This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.
RFC5831 - GOST R 34.11-94: Hash Function Algorithm
This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5830 - GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms
This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5829 - Link Relation Types for Simple Version Navigation between Web Resources
This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5828 - Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework
There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5827 - Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)
This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]
RFC5826 - Home Automation Routing Requirements in Low-Power and Lossy Networks
This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5825 - Displaying Downgraded Messages for Email Address Internationalization
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.
RFC5824 - Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN
Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.
RFC5820 - Extensions to OSPF to Support Mobile Ad Hoc Networking
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]
RFC5819 - IMAP4 Extension for Returning STATUS Information in Extended LIST
Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]
RFC5818 - Data Channel Status Confirmation Extensions for the Link Management Protocol
This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]
RFC5817 - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.
RFC5816 - ESSCertIDv2 Update for RFC 3161
This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]
RFC5815 - Definitions of Managed Objects for IP Flow Information Export
This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]
RFC5814 - Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.
RFC5813 - Forwarding and Control Element Separation (ForCES) MIB
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]
RFC5812 - Forwarding and Control Element Separation (ForCES) Forwarding Element Model
This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]
RFC5811 - SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol
This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]
RFC5810 - Forwarding and Control Element Separation (ForCES) Protocol Specification
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]
RFC5808 - Requirements for a Location-by-Reference Mechanism
This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5807 - Definition of Master Key between PANA Client and Enforcement Point
This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]
RFC5806 - Diversion Indication in SIP
This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.
RFC5805 - Lightweight Directory Access Protocol (LDAP) Transactions
Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. This document defines an Experimental Protocol for the Internet community.
RFC5804 - A Protocol for Remotely Managing Sieve Scripts
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]
RFC5803 - Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets
This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5802 - Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.
RFC5801 - Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]
RFC5798 - Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]
RFC5797 - FTP Command and Extension Registry
Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]
RFC5796 - Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]
RFC5795 - The RObust Header Compression (ROHC) Framework
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
RFC5794 - A Description of the ARIA Encryption Algorithm
This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5793 - PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]
RFC5792 - PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]
RFC5791 - RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete
This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5790 - Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]
RFC5789 - PATCH Method for HTTP
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]
RFC5788 - IMAP4 Keyword Registry
The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]
RFC5787 - OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
RFC5786 - Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions
OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.