| |
| RFC 5801 | Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family |
| |
| Authors: | S. Josefsson, N. Williams. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5801 |
|
This document describes how to use a Generic Security ServiceApplication Program Interface (GSS-API) mechanism in the SimpleAuthentication 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. |
|
| |
| RFC 5802 | Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |
| |
|
|
The secure authentication mechanism most widely deployed and used byInternet 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.
This specification describes a family of Simple Authentication andSecurity Layer (SASL; RFC 4422) authentication mechanisms called theSalted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. |
|
| |
| RFC 5803 | Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets |
| |
| Authors: | A. Melnikov. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5803 |
|
This memo describes how the "authPassword" Lightweight DirectoryAccess 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. |
|
| |
| RFC 5804 | 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. |
|
| |
| RFC 5805 | Lightweight Directory Access Protocol (LDAP) Transactions |
| |
| Authors: | K. Zeilenga. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5805 |
|
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. |
|
| |
| RFC 5806 | Diversion Indication in SIP |
| |
| Authors: | S. Levy, M. Mohali, Ed.. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5806 |
|
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 laterInformational RFCs. The original Abstract follows.
This document proposes an extension to the Session InitiationProtocol (SIP). This extension provides the ability for the calledSIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header,Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.
This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and AutomaticCall Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. |
|
| |
| RFC 5807 | Definition of Master Key between PANA Client and Enforcement Point |
| |
| Authors: | Y. Ohba, A. Yegin. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5807 |
|
This document defines a master key used between a client of theProtocol 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 ExtensibleAuthentication 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. |
|
| |
| RFC 5808 | Requirements for a Location-by-Reference Mechanism |
| |
| Authors: | R. Marshall, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5808 |
|
This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location UniformResource Identifier (URI) to handle location information within signaling and other Internet messaging. |
|
| |
| RFC 5810 | Forwarding and Control Element Separation (ForCES) Protocol Specification |
| |
| Authors: | A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7121, RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5810 |
|
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 aForCES 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). |
|
| |
| RFC 5811 | SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol |
| |
| Authors: | J. Hadi Salim, K. Ogawa. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5811 |
|
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 ControlTransmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. |
|
| |
| RFC 5812 | Forwarding and Control Element Separation (ForCES) Forwarding Element Model |
| |
| Authors: | J. Halpern, J. Hadi Salim. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7408 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5812 |
|
This document defines the forwarding element (FE) model used in theForwarding 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. |
|
| |
| RFC 5813 | Forwarding and Control Element Separation (ForCES) MIB |
| |
| Authors: | R. Haas. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5813 |
|
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 ControlElement Separation (ForCES) Network Element (NE). |
|
| |
| RFC 5814 | Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks |
| |
| Authors: | W. Sun, Ed., G. Zhang, Ed.. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5814 |
|
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-DropMultiplexers (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.
This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance inGMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. |
|
| |
| RFC 5815 | Definitions of Managed Objects for IP Flow Information Export |
| |
| Authors: | T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. |
| Date: | April 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6615 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5815 |
|
This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors including the basic configuration information. |
|
| |
| RFC 5816 | 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 HashAlgorithm (SHA-1). |
|
| |
| RFC 5817 | Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks |
| |
| Authors: | Z. Ali, JP. Vasseur, A. Zamfir, J. Newton. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5817 |
|
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.
This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to bothMPLS-TE and its Generalized MPLS (GMPLS) extensions. |
|
| |
| RFC 5818 | Data Channel Status Confirmation Extensions for the Link Management Protocol |
| |
| Authors: | D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. |
| Date: | April 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5818 |
|
This document defines simple additions to the Link ManagementProtocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-SwitchingRouters (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. |
|
| |
| RFC 5819 | IMAP4 Extension for Returning STATUS Information in Extended LIST |
| |
| Authors: | A. Melnikov, T. Sirainen. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5819 |
|
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 theLIST command. |
|
| |
| RFC 5820 | Extensions to OSPF to Support Mobile Ad Hoc Networking |
| |
| Authors: | A. Roy, Ed., M. Chandra, Ed.. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7137 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5820 |
|
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-OverlappingRelay), 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. |
|
| |
| RFC 5824 | Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN |
| |
| Authors: | K. Kumaki, Ed., R. Zhang, Y. Kamite. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5824 |
|
Today, customers expect to run triple-play services through BGP/MPLSIP-VPNs. Some service providers will deploy services that requestQuality 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.
Service providers can use both an MPLS and an MPLS TrafficEngineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) andRSVP-TE over a BGP/MPLS IP-VPN. |
|
| |
| RFC 5825 | 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. |
|
| |
| RFC 5826 | Home Automation Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | A. Brandt, J. Buron, G. Porcu. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5826 |
|
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. |
|
| |
| RFC 5827 | Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5827 |
|
This document proposes a new mechanism for TCP and Stream ControlTransmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "EarlyRetransmit" 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. |
|
| |
| RFC 5828 | Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework |
| |
| Authors: | D. Fedyk, L. Berger, L. Andersson. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5828 |
|
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. |
|
| |
| RFC 5829 | Link Relation Types for Simple Version Navigation between Web Resources |
| |
| Authors: | A. Brown, G. Clemm, J. Reschke, Ed.. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5829 |
|
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. |
|
| |
| RFC 5830 | GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms |
| |
|
|
This document is intended to be a source of information about theRussian 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 inInternet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. |
|
| |
| RFC 5831 | GOST R 34.11-94: Hash Function Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian 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 inInternet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. |
|
| |
| RFC 5832 | GOST R 34.10-2001: Digital Signature Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (calledGOST algorithms). Recently, Russian cryptography is being used inInternet 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. |
|
| |
| RFC 5833 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB |
| |
| Authors: | Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5833 |
|
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 AndProvisioning 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. |
|
| |
| RFC 5834 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 |
| |
| Authors: | Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5834 |
|
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 NetworkManagement Protocol (SNMP). |
|
| |
| RFC 5835 | Framework for Metric Composition |
| |
| Authors: | A. Morton, Ed., S. Van den Berghe, Ed.. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5835 |
|
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 theIETF. 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. |
|
| |
| RFC 5836 | Extensible Authentication Protocol (EAP) Early Authentication Problem Statement |
| |
| Authors: | Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed.. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5836 |
|
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. |
|
| |
| RFC 5837 | Extending ICMP for Interface and Next-Hop Identification |
| |
| Authors: | A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5837 |
|
This memo defines a data structure that can be appended to selectedICMP 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 theIP next hop to which the datagram would have been forwarded.
Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. |
|
| |
| RFC 5838 | 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 toOSPFv3 for supporting multiple AFs. |
|
| |
| RFC 5839 | An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification |
| |
| Authors: | A. Niemi, D. Willis, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5839 |
|
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. |
|
| |
| RFC 5840 | Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility |
| |
| Authors: | K. Grewal, G. Montenegro, M. Bhatia. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5840 |
|
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. |
|
| |
| RFC 5841 | TCP Option to Denote Packet Mood |
| |
| Authors: | R. Hay, W. Turkal. |
| Date: | 1 April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5841 |
|
This document proposes a new TCP option to denote packet mood. |
|
| |
| RFC 5842 | Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
| Authors: | G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5842 |
|
This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource.Servers are required to ensure the integrity of any bindings that they allow to be created. |
|
| |
| RFC 5843 | Additional Hash Algorithms for HTTP Instance Digests |
| |
| Authors: | A. Bryan. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5843 |
|
The IANA registry named "Hypertext Transfer Protocol (HTTP) DigestAlgorithm Values" defines values for digest algorithms used byInstance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. |
|
| |
| RFC 5844 | IPv4 Support for Proxy Mobile IPv6 |
| |
| Authors: | R. Wakikawa, S. Gundavelli. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5844 |
|
This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy MobileIPv6 domain to exchange signaling messages over an IPv4 transport network. |
|
| |
| RFC 5845 | Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 |
| |
| Authors: | A. Muhanna, M. Khalil, S. Gundavelli, K. Leung. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5845 |
|
This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiateGeneric Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. |
|
| |
| RFC 5846 | Binding Revocation for IPv6 Mobility |
| |
| Authors: | A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5846 |
|
This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. |
|
| |
| RFC 5847 | Heartbeat Mechanism for Proxy Mobile IPv6 |
| |
| Authors: | V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5847 |
|
Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. |
|
| |
| RFC 5848 | Signed Syslog Messages |
| |
| Authors: | J. Kelsey, J. Callas, A. Clemm. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5848 |
|
This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages.This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". |
|
| |
| RFC 5849 | The OAuth 1.0 Protocol |
| |
|
|
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. |
|
| |
| RFC 5850 | A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) |
| |
| Authors: | R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5850 |
|
This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol(SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history.This framework also describes other goals that embody the spirit ofSIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. |
|
| |
| RFC 5851 | Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks |
| |
| Authors: | S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5851 |
|
The purpose of this document is to define a framework for an AccessNode Control Mechanism between a Network Access Server (NAS) and anAccess Node (e.g., a Digital Subscriber Line Access Multiplexer(DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.
This document first identifies a number of use cases for which theAccess Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to supportANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. |
|
| |
| RFC 5852 | RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network |
| |
| Authors: | D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5852 |
|
In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) ControlPlane (Soft Permanent Connections - SPC) or a Management System(Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.
This memo describes an extension to GMPLS Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and theControl Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. |
|
| |
| RFC 5853 | Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments |
| |
| Authors: | J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5853 |
|
This document describes functions implemented in Session InitiationProtocol (SIP) intermediaries known as Session Border Controllers(SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. |
|
| |
| RFC 5854 | The Metalink Download Description Format |
| |
| Authors: | A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5854 |
|
This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. |
|
| |
| RFC 5855 | Nameservers for IPv4 and IPv6 Reverse Zones |
| |
|
|
This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). |
|
| |
| RFC 5856 | Integration of Robust Header Compression over IPsec Security Associations |
| |
| Authors: | E. Ertekin, R. Jasani, C. Christou, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5856 |
|
IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). |
|
| |
| RFC 5857 | IKEv2 Extensions to Support Robust Header Compression over IPsec |
| |
| Authors: | E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5857 |
|
In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). |
|
| |
| RFC 5858 | IPsec Extensions to Support Robust Header Compression over IPsec |
| |
| Authors: | E. Ertekin, C. Christou, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5858 |
|
Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC withIPsec, extensions to the Security Policy Database (SPD) and SecurityAssociation Database (SAD) are required. This document describes theIPsec extensions required to support ROHCoIPsec. |
|
| |
| RFC 5859 | TFTP Server Address Option for DHCPv4 |
| |
| Authors: | R. Johnson. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5859 |
|
This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic HostConfiguration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. |
|
| |
| RFC 5860 | Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks |
| |
| Authors: | M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5860 |
|
This document lists architectural and functional requirements for theOperations, Administration, and Maintenance of MPLS TransportProfile. These requirements apply to pseudowires, Label SwitchedPaths, and Sections. |
|
| |
| RFC 5861 | HTTP Cache-Control Extensions for Stale Content |
| |
| Authors: | M. Nottingham. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5861 |
|
This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. |
|
| |
| RFC 5862 | Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE |
| |
| Authors: | S. Yasukawa, A. Farrel. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5862 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. |
|
| |
| RFC 5863 | DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations |
| |
| Authors: | T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5863 |
|
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. |
|
| |
| RFC 5864 | DNS SRV Resource Records for AFS |
| |
|
|
This document specifies how to use DNS (Domain Name Service) SRV RRs(Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. |
|
| |
| RFC 5865 | A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic |
| |
|
|
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the ExpeditedForwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the ExpeditedForwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. |
|
| |
| RFC 5866 | Diameter Quality-of-Service Application |
| |
| Authors: | D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5866 |
|
This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. |
|
| |
| RFC 5867 | Building Automation Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5867 |
|
The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power andLossy Networks (LLNs) in various markets: industrial, commercial(building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. |
|
| |
| RFC 5868 | Problem Statement on the Cross-Realm Operation of Kerberos |
| |
| Authors: | S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5868 |
|
This document provides background information regarding large-scaleKerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.
This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field.Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem ofKerberos cross-realm operations. |
|
| |
| RFC 5869 | HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
| |
| Authors: | H. Krawczyk, P. Eronen. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5869 |
|
This document specifies a simple Hashed Message Authentication Code(HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. |
|
| |
| RFC 5870 | A Uniform Resource Identifier for Geographic Locations ('geo' URI) |
| |
| Authors: | A. Mayrhofer, C. Spanring. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5870 |
|
This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). |
|
| |
| RFC 5871 | IANA Allocation Guidelines for the IPv6 Routing Header |
| |
|
|
This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. |
|
| |
| RFC 5872 | IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
|
|
This document relaxes the IANA rules for the Protocol for CarryingAuthentication for Network Access (PANA). |
|
| |
| RFC 5873 | Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | Y. Ohba, A. Yegin. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5873 |
|
This document defines an extension to the Protocol for CarryingAuthentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. |
|
| |
| RFC 5874 | An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources |
| |
| Authors: | J. Rosenberg, J. Urpalainen. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5874 |
|
This specification defines a document format that can be used to indicate that a change has occurred in a document managed by theExtensible Markup Language (XML) Configuration Access Protocol(XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session InitiationProtocol (SIP) event package. |
|
| |
| RFC 5875 | An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package |
| |
| Authors: | J. Urpalainen, D. Willis, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5875 |
|
This document describes an "xcap-diff" SIP (Session InitiationProtocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes toExtensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. |
|
| |
| RFC 5876 | Updates to Asserted Identity in the Session Initiation Protocol (SIP) |
| |
|
|
The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of theP-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use ofP-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extendsRFC 3325 to cover these situations. |
|
| |
| RFC 5877 | The application/pkix-attr-cert Media Type for Attribute Certificates |
| |
| Authors: | R. Housley. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5877 |
|
This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. |
|
| |
| RFC 5878 | Transport Layer Security (TLS) Authorization Extensions |
| |
|
|
This document specifies authorization extensions to the TransportLayer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language(SAML) assertions, is exchanged in the supplemental data handshake message. |
|
| |
| RFC 5879 | Heuristics for Detecting ESP-NULL Packets |
| |
| Authors: | T. Kivinen, D. McDonald. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5879 |
|
This document describes a set of heuristics for distinguishing IPsecESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. |
|
| |
| RFC 5880 | Bidirectional Forwarding Detection (BFD) |
| |
|
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. |
|
| |
| RFC 5881 | Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5881 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over IPv4 and IPv6 for single IP hops. |
|
| |
| RFC 5882 | Generic Application of Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5882 |
|
This document describes the generic application of the BidirectionalForwarding Detection (BFD) protocol. |
|
| |
| RFC 5883 | Bidirectional Forwarding Detection (BFD) for Multihop Paths |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5883 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over multihop paths, including unidirectional links. |
|
| |
| RFC 5884 | Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. |
| Date: | June 2010 |
| Formats: | txt html json |
| Updates: | RFC 1122 |
| Updated by: | RFC 7726 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5884 |
|
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label SwitchedPath (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination ofLSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability ofBFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. |
|
| |
| RFC 5885 | Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) |
| |
|
|
This document describes Connectivity Verification (CV) Types usingBidirectional Forwarding Detection (BFD) with Virtual CircuitConnectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. |
|
| |
| RFC 5886 | A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture |
| |
| Authors: | JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5886 |
|
A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) LabelSwitched Paths (LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".
In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in thePCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. |
|
| |
| RFC 5887 | Renumbering Still Needs Work |
| |
| Authors: | B. Carpenter, R. Atkinson, H. Flinck. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5887 |
|
This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. |
|
| |
| RFC 5888 | The Session Description Protocol (SDP) Grouping Framework |
| |
|
|
In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. |
|
| |
| RFC 5889 | IP Addressing Model in Ad Hoc Networks |
| |
| Authors: | E. Baccelli, Ed., M. Townsley, Ed.. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5889 |
|
This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. |
|
| |
| RFC 5890 | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework |
| |
|
|
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized DomainNames for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. |
|
| |
| RFC 5891 | Internationalized Domain Names in Applications (IDNA): Protocol |
| |
|
|
This document is the revised protocol definition forInternationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names inApplications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. |
|
| |
| RFC 5892 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) |
| |
|
|
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).
It is part of the specification of Internationalizing Domain Names inApplications 2008 (IDNA2008). |
|
| |
| RFC 5893 | Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) |
| |
| Authors: | H. Alvestrand, Ed., C. Karp. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5893 |
|
The use of right-to-left scripts in Internationalized Domain Names(IDNs) has presented several challenges. This memo provides a newBidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. |
|
| |
| RFC 5894 | Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale |
| |
| Authors: | J. Klensin. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5894 |
|
Several years have passed since the original protocol forInternationalized Domain Names (IDNs) was completed and deployed.During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. |
|
| |
| RFC 5895 | Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 |
| |
| Authors: | P. Resnick, P. Hoffman. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5895 |
|
In the original version of the Internationalized Domain Names inApplications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS).The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of"permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. |
|
| |
| RFC 5896 | Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy |
| |
|
|
Several Generic Security Service Application Program Interface(GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, includingCIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC2743). |
|
| |
| RFC 5897 | Identification of Communications Services in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5897 |
|
This document considers the problem of service identification in theSession Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. |
|
| |
| RFC 5898 | Connectivity Preconditions for Session Description Protocol (SDP) Media Streams |
| |
| Authors: | F. Andreasen, G. Camarillo, D. Oran, D. Wing. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5898 |
|
This document defines a new connectivity precondition for the SessionDescription Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such asTCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. |
|
