The RFC Archive   RFC    « Jump to any RFC number directly

RFC Home	Full RFC Index	Recent RFCs	RFC Standards	Best Current Practice	RFC Errata	1 April RFC

Index: RFC 5901-6000

RFC 5901

Extensions to the IODEF-Document Class for Reporting Phishing

Summary  Publication date: Jul 2010 This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents.

RFC 5902	IAB Thoughts on IPv6 Network Address Translation
	Summary  Publication date: Jul 2010 There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.

RFC 5903

Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2

Summary  Publication date: Jun 2010 This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753.

RFC 5904	RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support
	Summary  Publication date: Jun 2010 This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

RFC 5905

Network Time Protocol Version 4: Protocol and Algorithms Specification

Summary  Publication date: Jun 2010 The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.

RFC 5906

Network Time Protocol Version 4: Autokey Specification

Summary  Publication date: Jun 2010 This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org.

RFC 5907

Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)

Summary  Publication date: Jun 2010 The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort.

RFC 5908	Network Time Protocol (NTP) Server Option for DHCPv6
	Summary  Publication date: Jun 2010 The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts.

RFC 5909

Securing Neighbor Discovery Proxy: Problem Statement

Summary  Publication date: Jul 2010 Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages. Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND.

RFC 5910

Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Summary  Publication date: May 2010 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310.

RFC 5911	New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
	Summary  Publication date: Jun 2010 The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.

RFC 5912

New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)

Summary  Publication date: Jun 2010 The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.

RFC 5913

Clearance Attribute and Authority Clearance Constraints Certificate Extension

Summary  Publication date: Jun 2010 This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject.

RFC 5914

Trust Anchor Format

Summary  Publication date: Jun 2010 This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements.

RFC 5915	Elliptic Curve Private Key Structure
	Summary  Publication date: Jun 2010 This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG).

RFC 5916	Device Owner Attribute
	Summary  Publication date: Jun 2010 This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates.

RFC 5917	Clearance Sponsor Attribute
	Summary  Publication date: Jun 2010 This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute.

RFC 5918	Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
	Summary  Publication date: Aug 2010 The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility.

RFC 5919

Signaling LDP Label Advertisement Completion

Summary  Publication date: Aug 2010 There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment.

RFC 5920

Security Framework for MPLS and GMPLS Networks

Summary  Publication date: Jul 2010 This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.

RFC 5921

A Framework for MPLS in Transport Networks

Summary  Publication date: Jul 2010 This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS- TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

RFC 5922

Domain Certificates in the Session Initiation Protocol (SIP)

Summary  Publication date: Jun 2010 This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates.

RFC 5923

Connection Reuse in the Session Initiation Protocol (SIP)

Summary  Publication date: Jun 2010 This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP.

RFC 5924	Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
	Summary  Publication date: Jun 2010 This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.

RFC 5925

The TCP Authentication Option

Summary  Publication date: Jun 2010 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP- AO uses a different option identifier than TCP MD5, even though TCP- AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.

RFC 5926

Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)

Summary  Publication date: Jun 2010 The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs).

RFC 5927	ICMP Attacks against TCP
	Summary  Publication date: Jul 2010 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.

RFC 5928	Traversal Using Relays around NAT (TURN) Resolution Mechanism
	Summary  Publication date: Aug 2010 This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation.

RFC 5929

Channel Bindings for TLS

Summary  Publication date: Jul 2010 This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry.

RFC 5930	Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
	Summary  Publication date: Jul 2010 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange.

RFC 5931

Extensible Authentication Protocol (EAP) Authentication Using Only a Password

Summary  Publication date: Aug 2010 This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.

RFC 5932	Camellia Cipher Suites for TLS
	Summary  Publication date: Jun 2010 This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132.

RFC 5933	Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
	Summary  Publication date: Jul 2010 This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).

RFC 5934

Trust Anchor Management Protocol (TAMP)

Summary  Publication date: Aug 2010 This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects.

RFC 5935	Expressing SNMP SMI Datatypes in XML Schema Definition Language
	Summary  Publication date: Aug 2010 This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism.

RFC 5936

DNS Zone Transfer Protocol (AXFR)

Summary  Publication date: Jun 2010 The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism.

RFC 5937	Using Trust Anchor Constraints during Certification Path Processing
	Summary  Publication date: Aug 2010 This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.

RFC 5938

Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)

Summary  Publication date: Aug 2010 The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time.

RFC 5939

Session Description Protocol (SDP) Capability Negotiation

Summary  Publication date: Sep 2010 The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents.

RFC 5940

Additional Cryptographic Message Syntax (CMS) Revocation Information Choices

Summary  Publication date: Aug 2010 The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses.

RFC 5941	Sharing Transaction Fraud Data
	Summary  Publication date: Aug 2010 This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format.

RFC 5942

IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes

Summary  Publication date: Jul 2010 IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861.

RFC 5943

A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing

Summary  Publication date: Aug 2010 The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings).

RFC 5944

IP Mobility Support for IPv4, Revised

Summary  Publication date: Nov 2010 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.

RFC 5945

Resource Reservation Protocol (RSVP) Proxy Approaches

Summary  Publication date: Oct 2010 The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described.

RFC 5946

Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy

Summary  Publication date: Oct 2010 Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions.

RFC 5947

Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)

Summary  Publication date: Sep 2010 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.

RFC 5948

Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16

Summary  Publication date: Aug 2010 IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer. This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16.

RFC 5949

Fast Handovers for Proxy Mobile IPv6

Summary  Publication date: Sep 2010 Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6. When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations.

RFC 5950

Network Management Framework for MPLS-based Transport Networks

Summary  Publication date: Sep 2010 This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS- TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.

RFC 5951

Network Management Requirements for MPLS-based Transport Networks

Summary  Publication date: Sep 2010 This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.

RFC 5952

A Recommendation for IPv6 Address Text Representation

Summary  Publication date: Aug 2010 As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.

RFC 5953

Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)

Summary  Publication date: Aug 2010 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.

RFC 5954	Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261
	Summary  Publication date: Aug 2010 This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses.

RFC 5955	The application/timestamped-data Media Type
	Summary  Publication date: Aug 2010 This document defines a new media type for TimeStampedData envelopes as described in RFC 5544.

RFC 5956

Forward Error Correction Grouping Semantics in the Session Description Protocol

Summary  Publication date: Sep 2010 This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing.

RFC 5957	Display-Based Address Sorting for the IMAP4 SORT Extension
	Summary  Publication date: Jul 2010 This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields.

RFC 5958

Asymmetric Key Packages

Summary  Publication date: Aug 2010 This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208.

RFC 5959	Algorithms for Asymmetric Key Package Content Type
	Summary  Publication date: Aug 2010 This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData.

RFC 5960

MPLS Transport Profile Data Plane Architecture

Summary  Publication date: Aug 2010 The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network.

RFC 5961

Improving TCP's Robustness to Blind In-Window Attacks

Summary  Publication date: Aug 2010 TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack.

RFC 5962

Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)

Summary  Publication date: Sep 2010 The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity.

RFC 5963

IPv6 Deployment in Internet Exchange Points (IXPs)

Summary  Publication date: Aug 2010 This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4.

RFC 5964	Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries
	Summary  Publication date: Aug 2010 This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described.

RFC 5965	An Extensible Format for Email Feedback Reports
	Summary  Publication date: Aug 2010 This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email.

RFC 5966	DNS Transport over TCP - Implementation Requirements
	Summary  Publication date: Aug 2010 This document updates the requirements for the support of TCP as a transport protocol for DNS implementations.

RFC 5967	The application/pkcs10 Media Type
	Summary  Publication date: Aug 2010 This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.

RFC 5968

Guidelines for Extending the RTP Control Protocol (RTCP)

Summary  Publication date: Sep 2010 The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.

RFC 5969	IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
	Summary  Publication date: Aug 2010 This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism.

RFC 5970	DHCPv6 Options for Network Boot
	Summary  Publication date: Sep 2010 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network.

RFC 5971

GIST: General Internet Signalling Transport

Summary  Publication date: Oct 2010 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.

RFC 5972	General Internet Signaling Transport (GIST) State Machine
	Summary  Publication date: Oct 2010 This document describes state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented.

RFC 5973

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Summary  Publication date: Oct 2010 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.

RFC 5974

NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling

Summary  Publication date: Oct 2010 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules.

RFC 5975

QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)

Summary  Publication date: Oct 2010 The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.

RFC 5976	Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
	Summary  Publication date: Oct 2010 This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.

RFC 5977

RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv

Summary  Publication date: Oct 2010 This document describes a Next Steps in Signaling (NSIS) Quality-of- Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.

RFC 5978

Using and Extending the NSIS Protocol Family

Summary  Publication date: Oct 2010 This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.

RFC 5979

NSIS Operation over IP Tunnels

Summary  Publication date: Mar 2011 NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.

RFC 5980	NSIS Protocol Operation in Mobile Environments
	Summary  Publication date: Mar 2011 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols.

RFC 5981

Authorization for NSIS Signaling Layer Protocols

Summary  Publication date: Feb 2011 Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.

RFC 5982

IP Flow Information Export (IPFIX) Mediation: Problem Statement

Summary  Publication date: Aug 2010 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems.

RFC 5983	Mailing Lists and Internationalized Email Addresses
	Summary  Publication date: Oct 2010 This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations.

RFC 5984	Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding
	Summary  Publication date: Apr 2011 This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.

RFC 5985

HTTP-Enabled Location Delivery (HELD)

Summary  Publication date: Sep 2010 This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer.

RFC 5986

Discovering the Local Location Information Server (LIS)

Summary  Publication date: Sep 2010 Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.

RFC 5987

Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters

Summary  Publication date: Aug 2010 By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.

RFC 5988	Web Linking
	Summary  Publication date: Oct 2010 This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.

RFC 5989

A SIP Event Package for Subscribing to Changes to an HTTP Resource

Summary  Publication date: Oct 2010 The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so.

RFC 5990

Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)

Summary  Publication date: Sep 2010 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

RFC 5991	Teredo Security Updates
	Summary  Publication date: Sep 2010 The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.

RFC 5992

Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic

Summary  Publication date: Oct 2010 This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations.

RFC 5993	RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)
	Summary  Publication date: Oct 2010 This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.

RFC 5994

Application of Ethernet Pseudowires to MPLS Transport Networks

Summary  Publication date: Oct 2010 Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks. Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available. This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP.

RFC 5995

Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections

Summary  Publication date: Sep 2010 The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.

RFC 5996	Internet Key Exchange Protocol Version 2 (IKEv2)
	Summary  Publication date: Sep 2010 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718.

RFC 5997	Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
	Summary  Publication date: Aug 2010 This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.

RFC 5998

An Extension for EAP-Only Authentication in IKEv2

Summary  Publication date: Sep 2010 IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures.

RFC-ARCHIVE.ORG

© all RFCs, STDs, BCPs: The IETF Trust
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen