| |
| RFC 4501 | Domain Name System Uniform Resource Identifiers |
| |
| Authors: | S. Josefsson. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4501 |
|
This document defines Uniform Resource Identifiers for Domain NameSystem resources. |
|
| |
| RFC 4502 | Remote Network Monitoring Management Information Base Version 2 |
| |
|
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.
This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. |
|
| |
| RFC 4503 | A Description of the Rabbit Stream Cipher Algorithm |
| |
| Authors: | M. Boesgaard, M. Vesterager, E. Zenner. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4503 |
|
This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. |
|
| |
| RFC 4504 | SIP Telephony Device Requirements and Configuration |
| |
| Authors: | H. Sinnreich, Ed., S. Lass, C. Stredicke. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4504 |
|
This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones andPC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings. |
|
| |
| RFC 4505 | Anonymous Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain- text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. |
|
| |
| RFC 4506 | XDR: External Data Representation Standard |
| |
|
|
This document describes the External Data Representation Standard(XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. |
|
| |
| RFC 4507 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
| Authors: | J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4507 |
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. |
|
| |
| RFC 4508 | Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method |
| |
|
|
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. |
|
| |
| RFC 4509 | Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) |
| |
| Authors: | W. Hardaker. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4509 |
|
This document specifies how to use the SHA-256 digest type in DNSDelegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. |
|
| |
| RFC 4510 | Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map |
| |
| Authors: | K. Zeilenga, Ed.. |
| Date: | June 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4510 |
|
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. |
|
| |
| RFC 4511 | Lightweight Directory Access Protocol (LDAP): The Protocol |
| |
|
|
This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol(LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory AccessProtocol (DAP). |
|
| |
| RFC 4512 | Lightweight Directory Access Protocol (LDAP): Directory Information Models |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. |
|
| |
| RFC 4513 | Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms |
| |
|
|
This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.
This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and theSimple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.
This document, together with other documents in the LDAP TechnicalSpecification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. |
|
| |
| RFC 4514 | Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names |
| |
|
|
The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol(LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. |
|
| |
| RFC 4515 | Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters |
| |
| Authors: | M. Smith, Ed., T. Howes. |
| Date: | June 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2254 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4515 |
|
Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. |
|
| |
| RFC 4516 | Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator |
| |
| Authors: | M. Smith, Ed., T. Howes. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 2255 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4516 |
|
This document describes a format for a Lightweight Directory AccessProtocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. |
|
| |
| RFC 4517 | Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules |
| |
|
|
Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. |
|
| |
| RFC 4518 | Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4518 |
|
The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use inLDAP. |
|
| |
| RFC 4519 | Lightweight Directory Access Protocol (LDAP): Schema for User Applications |
| |
|
|
This document is an integral part of the Lightweight Directory AccessProtocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as WhitePages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. |
|
| |
| RFC 4520 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
|
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 4521 | Considerations for Lightweight Directory Access Protocol (LDAP) Extensions |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. |
|
| |
| RFC 4522 | Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option |
| |
| Authors: | S. Legg. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4522 |
|
Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. |
|
| |
| RFC 4523 | Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates |
| |
|
| |
| RFC 4524 | COSINE LDAP/X.500 Schema |
| |
|
|
This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE andInternet X.500 pilot projects.
This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. |
|
| |
| RFC 4525 | Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4525 |
|
This document describes an extension to the Lightweight DirectoryAccess Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre- read or post-read control extension. |
|
| |
| RFC 4526 | Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4526 |
|
This document extends the Lightweight Directory Access Protocol(LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. |
|
| |
| RFC 4527 | Lightweight Directory Access Protocol (LDAP) Read Entry Controls |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4527 |
|
This document specifies an extension to the Lightweight DirectoryAccess Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. |
|
| |
| RFC 4528 | Lightweight Directory Access Protocol (LDAP) Assertion Control |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4528 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. |
|
| |
| RFC 4529 | Requesting Attributes by Object Class in the Lightweight Directory Access Protocol |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4529 |
|
The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. |
|
| |
| RFC 4530 | Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4530 |
|
This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. |
|
| |
| RFC 4531 | Lightweight Directory Access Protocol (LDAP) Turn Operation |
| |
|
|
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. |
|
| |
| RFC 4532 | Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4532 |
|
This specification provides a mechanism for Lightweight DirectoryAccess Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP"Who am I?" operation. |
|
| |
| RFC 4533 | The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation |
| |
| Authors: | K. Zeilenga, J.H. Choi. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4533 |
|
This specification describes the Lightweight Directory AccessProtocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the DirectoryInformation Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. |
|
| |
| RFC 4534 | Group Security Policy Token v1 |
| |
| Authors: | A. Colegrove, H. Harney. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4534 |
|
The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. |
|
| |
| RFC 4535 | GSAKMP: Group Secure Association Key Management Protocol |
| |
| Authors: | H. Harney, U. Meth, A. Colegrove, G. Gross. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4535 |
|
This document specifies the Group Secure Association Key ManagementProtocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. |
|
| |
| RFC 4536 | The application/smil and application/smil+xml Media Types |
| |
| Authors: | P. Hoschka. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4536 |
|
This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. |
|
| |
| RFC 4537 | Kerberos Cryptosystem Negotiation Extension |
| |
| Authors: | L. Zhu, P. Leach, K. Jaganathan. |
| Date: | June 2006 |
| Formats: | txt html json |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4537 |
|
This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. |
|
| |
| RFC 4538 | Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4538 |
|
This specification defines the Target-Dialog header field for theSession Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. |
|
| |
| RFC 4539 | Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) |
| |
| Authors: | T. Edwards. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4539 |
|
This document serves to register a media type for the Society ofMotion Picture and Television Engineers (SMPTE) Material ExchangeFormat (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. |
|
| |
| RFC 4540 | NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 |
| |
| Authors: | M. Stiemerling, J. Quittek, C. Cadar. |
| Date: | May 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4540 |
|
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. |
|
| |
| RFC 4541 | Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches |
| |
| Authors: | M. Christensen, K. Kimball, F. Solensky. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4541 |
|
This memo describes the recommendations for Internet Group ManagementProtocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes andEthernet-specific encapsulation issues, are also considered. |
|
| |
| RFC 4542 | Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite |
| |
|
|
RFCs 3689 and 3690 detail requirements for an EmergencyTelecommunications Service (ETS), of which an Internet EmergencyPreparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-LevelPrecedence and Preemption (MLPP) and Government EmergencyTelecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. |
|
| |
| RFC 4543 | The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH |
| |
| Authors: | D. McGrew, J. Viega. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4543 |
|
This memo describes the use of the Advanced Encryption Standard (AES)Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsecEncapsulating Security Payload (ESP) and Authentication Header (AH).GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. |
|
| |
| RFC 4544 | Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Bakke, M. Krueger, T. McSweeney, J. Muchow. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7147 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4544 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing a client using theInternet Small Computer System Interface (iSCSI) protocol (SCSI overTCP). |
|
| |
| RFC 4545 | Definitions of Managed Objects for IP Storage User Identity Authorization |
| |
| Authors: | M. Bakke, J. Muchow. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4545 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. |
|
| |
| RFC 4546 | Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP) based management of the Radio Frequency(RF) interfaces for systems compliant with the Data Over CableService Interface Specifications (DOCSIS). |
|
| |
| RFC 4547 | Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems |
| |
| Authors: | A. Ahmad, G. Nakanishi. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4547 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification(DOCSIS) compliant Cable Modems and Cable Modem Termination Systems.This MIB is defined as an extension to the DOCSIS Cable Device MIB.
This memo specifies a MIB module in a manner that is compliant to theStructure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. |
|
| |
| RFC 4548 | Internet Code Point (ICP) Assignments for NSAP Addresses |
| |
|
|
This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service AccessPoint (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T RecommendationX.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. |
|
| |
| RFC 4549 | Synchronization Operations for Disconnected IMAP4 Clients |
| |
| Authors: | A. Melnikov, Ed.. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4549 |
|
This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.
This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. |
|
| |
| RFC 4550 | Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
| Authors: | S. Maes, A. Melnikov. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4550 |
|
This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). |
|
| |
| RFC 4551 | IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization |
| |
|
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
This document defines an extension to IMAP (RFC 3501). |
|
| |
| RFC 4552 | Authentication/Confidentiality for OSPFv3 |
| |
| Authors: | M. Gupta, N. Melam. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4552 |
|
This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AuthenticationHeader/Encapsulating Security Payload (AH/ESP) extension header. |
|
| |
| RFC 4553 | Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) |
| |
| Authors: | A. Vainshtein, Ed., YJ. Stein, Ed.. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4553 |
|
This document describes a pseudowire encapsulation for Time DivisionMultiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. |
|
| |
| RFC 4554 | Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks |
| |
| Authors: | T. Chown. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4554 |
|
Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how suchVLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. |
|
| |
| RFC 4555 | IKEv2 Mobility and Multihoming Protocol (MOBIKE) |
| |
| Authors: | P. Eronen. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4555 |
|
This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsecSecurity Associations to change. A mobile Virtual Private Network(VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. |
|
| |
| RFC 4556 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
|
|
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. |
|
| |
| RFC 4557 | Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
| Authors: | L. Zhu, K. Jaganathan, N. Williams. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4557 |
|
This document defines a mechanism to enable in-band transmission ofOnline Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography forInitial Authentication in Kerberos (PKINIT), which is the KerberosVersion 5 extension that provides for the use of public key cryptography. |
|
| |
| RFC 4558 | Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement |
| |
| Authors: | Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4558 |
|
Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure forResource reSerVation Protocol-Traffic Engineering (RSVP-TE).Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to bothMulti-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. |
|
| |
| RFC 4559 | SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows |
| |
| Authors: | K. Jaganathan, L. Zhu, J. Brezak. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4559 |
|
This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in MicrosoftWindows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of"negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple AndProtected Negotiate (SPNEGO) implementation are not provided in this document. |
|
| |
| RFC 4560 | Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations |
| |
| Authors: | J. Quittek, Ed., K. White, Ed.. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 2925 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4560 |
|
This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. |
|
| |
| RFC 4561 | Definition of a Record Route Object (RRO) Node-Id Sub-Object |
| |
| Authors: | J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4561 |
|
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic EngineeringLabel Switched Path (TE LSP) on a downstream Label Switching Router(LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an AutonomousSystem (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of anArea Border Router (ABR) or Autonomous System Border Router (ASBR).This document specifies the use of existing Record Route Object (RRO)IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS FastReroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. |
|
| |
| RFC 4562 | MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network |
| |
| Authors: | T. Melsen, S. Blake. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4562 |
|
This document describes a mechanism to ensure layer-2 separation ofLocal Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
The mechanism - called "MAC-Forced Forwarding" - implements anAddress Resolution Protocol (ARP) proxy function that prohibitsEthernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. |
|
| |
| RFC 4563 | The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | E. Carrara, V. Lehtovirta, K. Norrman. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4563 |
|
This memo specifies a new Type (the Key ID Information Type) for theGeneral Extension Payload in the Multimedia Internet KEYing (MIKEY)Protocol. This is used in, for example, the MultimediaBroadcast/Multicast Service specified in the Third GenerationPartnership Project. |
|
| |
| RFC 4564 | Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4564 |
|
This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability amongWireless Local Area Network (WLAN) devices of alternative designs. |
|
| |
| RFC 4565 | Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols |
| |
| Authors: | D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4565 |
|
This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26,2005. |
|
| |
| RFC 4566 | SDP: Session Description Protocol |
| |
|
|
This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. |
|
| |
| RFC 4567 | Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) |
| |
| Authors: | J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4567 |
|
This document defines general extensions for Session DescriptionProtocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia InternetKEYing (MIKEY) key management protocol is also defined. |
|
| |
| RFC 4568 | Session Description Protocol (SDP) Security Descriptions for Media Streams |
| |
| Authors: | F. Andreasen, M. Baugher, D. Wing. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4568 |
|
This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. |
|
| |
| RFC 4569 | Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag |
| |
| Authors: | G. Camarillo. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4569 |
|
This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. |
|
| |
| RFC 4570 | Session Description Protocol (SDP) Source Filters |
| |
| Authors: | B. Quinn, R. Finlayson. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4570 |
|
This document describes how to adapt the Session Description Protocol(SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations.In particular, an inclusive source-filter can be used to specify aSource-Specific Multicast (SSM) session. |
|
| |
| RFC 4571 | Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport |
| |
| Authors: | J. Lazzaro. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4571 |
|
This memo defines a method for framing Real-time Transport Protocol(RTP) and RTP Control Protocol (RTCP) packets onto connection- oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. |
|
| |
| RFC 4572 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document extends and updates RFC 4145. |
|
| |
| RFC 4573 | MIME Type Registration for RTP Payload Format for H.224 |
| |
| Authors: | R. Even, A. Lochbaum. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4573 |
|
In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. |
|
| |
| RFC 4574 | The Session Description Protocol (SDP) Label Attribute |
| |
| Authors: | O. Levin, G. Camarillo. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4574 |
|
This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. |
|
| |
| RFC 4575 | A Session Initiation Protocol (SIP) Event Package for Conference State |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4575 |
|
This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. |
|
| |
| RFC 4576 | Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen, P. Psenak, P. Pillay-Esnault. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4576 |
|
This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLSIP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge(CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by anyPE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (LinkState Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. |
|
| |
| RFC 4577 | OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen, P. Psenak, P. Pillay-Esnault. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updates: | RFC 4364 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4577 |
|
Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers(CE routers) are routing peers of provider edge routers (PE routers).The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, andMultiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLSIP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open ShortestPath First (OSPF) protocol.
This document updates RFC 4364. |
|
| |
| RFC 4578 | Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) |
| |
| Authors: | M. Johnston, S. Venaas, Ed.. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4578 |
|
We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible FirmwareInterface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. |
|
| |
| RFC 4579 | Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents |
| |
|
|
This specification defines conferencing call control features for theSession Initiation Protocol (SIP). This document builds on theConferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference- unaware, conference-aware, and focus UAs. The use of UniformResource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. |
|
| |
| RFC 4580 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option |
| |
| Authors: | B. Volz. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4580 |
|
This memo defines a new Relay Agent Subscriber-ID option for theDynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. |
|
| |
| RFC 4581 | Cryptographically Generated Addresses (CGA) Extension Field Format |
| |
|
|
This document defines a Type-Length-Value format forCryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. |
|
| |
| RFC 4582 | The Binary Floor Control Protocol (BFCP) |
| |
|
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. |
|
| |
| RFC 4583 | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
|
This document specifies how to describe Binary Floor Control Protocol(BFCP) streams in Session Description Protocol (SDP) descriptions.User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. |
|
| |
| RFC 4584 | Extension to Sockets API for Mobile IPv6 |
| |
| Authors: | S. Chakrabarti, E. Nordmark. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4584 |
|
This document describes data structures and API support for MobileIPv6 as an extension to the Advanced Socket API for IPv6.
Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information forMobility Header messages, Home Address destination options, andRouting Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. |
|
| |
| RFC 4585 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) |
| |
|
|
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of theReal-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to theAudio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. |
|
| |
| RFC 4586 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations |
| |
| Authors: | C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4586 |
|
This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time TransportControl Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. |
|
| |
| RFC 4587 | RTP Payload Format for H.261 Video Streams |
| |
|
|
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.
The memo also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
This specification obsoletes RFC 2032. |
|
| |
| RFC 4588 | RTP Retransmission Payload Format |
| |
| Authors: | J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4588 |
|
RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions.Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-timeTransport Control Protocol (RTCP) feedback as defined in the extendedRTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. |
|
| |
| RFC 4589 | Location Types Registry |
| |
| Authors: | H. Schulzrinne, H. Tschofenig. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4589 |
|
This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. |
|
| |
| RFC 4590 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | July 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4590 |
|
This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP. |
|
| |
| RFC 4591 | Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. |
| Date: | August 2006 |
| Formats: | txt html json |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4591 |
|
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelFrame Relay over L2TPv3, including frame encapsulation, virtual- circuit creation and deletion, and status change notification. |
|
| |
| RFC 4592 | The Role of Wildcards in the Domain Name System |
| |
|
|
This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. |
|
| |
| RFC 4593 | Generic Threats to Routing Protocols |
| |
| Authors: | A. Barbir, S. Murphy, Y. Yang. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4593 |
|
Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. |
|
| |
| RFC 4594 | Configuration Guidelines for DiffServ Service Classes |
| |
|
|
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them usingDifferentiated Services Code Points (DSCPs), traffic conditioners,Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. |
|
| |
| RFC 4595 | Use of IKEv2 in the Fibre Channel Security Association Management Protocol |
| |
| Authors: | F. Maino, D. Black. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4595 |
|
This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the FibreChannel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies theseIKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. |
|
| |
| RFC 4596 | Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension |
| |
| Authors: | J. Rosenberg, P. Kyzivat. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4596 |
|
This document contains guidelines for usage of the Caller PreferencesExtension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. |
|
| |
| RFC 4597 | Conferencing Scenarios |
| |
| Authors: | R. Even, N. Ismail. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4597 |
|
This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. |
|
| |
| RFC 4598 | Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio |
| |
| Authors: | B. Link. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4598 |
|
This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data.E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. |
|
