| |
| RFC 5000 | Internet Official Protocol Standards |
| |
|
|
This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, andExperimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.
For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. |
|
| |
| RFC 5001 | DNS Name Server Identifier (NSID) Option |
| |
| Authors: | R. Austein. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5001 |
|
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself.This note defines a protocol extension to support this functionality. |
|
| |
| RFC 5002 | The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) |
| |
|
|
This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS(IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destinationSIP URI of a particular SIP request. |
|
| |
| RFC 5003 | Attachment Individual Identifier (AII) Types for Aggregation |
| |
| Authors: | C. Metz, L. Martini, F. Balus, J. Sugimoto. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5003 |
|
The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and VirtualPrivate Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. |
|
| |
| RFC 5004 | Avoid BGP Best Path Transitions from One External to Another |
| |
| Authors: | E. Chen, S. Sangli. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5004 |
|
In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. |
|
| |
| RFC 5005 | Feed Paging and Archiving |
| |
| Authors: | M. Nottingham. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5005 |
|
This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents.This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". |
|
| |
| RFC 5006 | IPv6 Router Advertisement Option for DNS Configuration |
| |
| Authors: | J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. |
| Date: | September 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6106 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5006 |
|
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts. |
|
| |
| RFC 5007 | DHCPv6 Leasequery |
| |
| Authors: | J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5007 |
|
This document specifies a leasequery exchange for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. |
|
| |
| RFC 5008 | Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
|
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 3851. |
|
| |
| RFC 5009 | Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media |
| |
| Authors: | R. Ejzak. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5009 |
|
This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European TelecommunicationsStandards Institute (ETSI) Telecommunications and Internet-convergedServices and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation PartnershipProject (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. |
|
| |
| RFC 5010 | The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption |
| |
| Authors: | K. Kinnear, M. Normoyle, M. Stapp. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5010 |
|
This memo defines a new suboption of the Dynamic Host ConfigurationProtocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. |
|
| |
| RFC 5011 | Automated Updates of DNS Security (DNSSEC) Trust Anchors |
| |
|
|
This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
This mechanism will require changes to resolver management behavior(but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. |
|
| |
| RFC 5012 | Requirements for Emergency Context Resolution with Internet Technologies |
| |
| Authors: | H. Schulzrinne, R. Marshall, Ed.. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5012 |
|
This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, whereInternet protocols are used end to end. |
|
| |
| RFC 5013 | The Dublin Core Metadata Element Set |
| |
|
|
This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. |
|
| |
| RFC 5014 | IPv6 Socket API for Source Address Selection |
| |
| Authors: | E. Nordmark, S. Chakrabarti, J. Laganier. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5014 |
|
The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API.However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. |
|
| |
| RFC 5015 | Bidirectional Protocol Independent Multicast (BIDIR-PIM) |
| |
| Authors: | M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8736, RFC 9436 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5015 |
|
This document discusses Bidirectional PIM (BIDIR-PIM), a variant ofPIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. |
|
| |
| RFC 5016 | Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol |
| |
| Authors: | M. Thomas. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5016 |
|
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable(SHOULD). |
|
| |
| RFC 5017 | MIB Textual Conventions for Uniform Resource Identifiers (URIs) |
| |
| Authors: | D. McWalter, Ed.. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5017 |
|
This MIB module defines textual conventions to represent STD 66Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). |
|
| |
| RFC 5018 | Connection Establishment in the Binary Floor Control Protocol (BFCP) |
| |
|
|
This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). |
|
| |
| RFC 5019 | The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments |
| |
| Authors: | A. Deacon, R. Hurst. |
| Date: | September 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5019 |
|
This specification defines a profile of the Online Certificate StatusProtocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure(PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. |
|
| |
| RFC 5020 | The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute |
| |
| Authors: | K. Zeilenga. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5020 |
|
This document describes the Lightweight Directory Access Protocol(LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. |
|
| |
| RFC 5021 | Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP |
| |
|
|
This document describes an extensibility mechanism for the KerberosV5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiateTCP-specific Kerberos extensions. |
|
| |
| RFC 5022 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | September 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 4722 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5022 |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 5023 | The Atom Publishing Protocol |
| |
| Authors: | J. Gregorio, Ed., B. de hOra, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5023 |
|
The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. |
|
| |
| RFC 5024 | ODETTE File Transfer Protocol 2.0 |
| |
|
|
This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic MessageSyntax, and provides signed receipts for the acknowledgement of received files.
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used withTCP/IP, X.25, and ISDN-based networks. |
|
| |
| RFC 5025 | Presence Authorization Rules |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5025 |
|
Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration AccessProtocol (XCAP), although other techniques are permitted. |
|
| |
| RFC 5026 | Mobile IPv6 Bootstrapping in Split Scenario |
| |
| Authors: | G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5026 |
|
A Mobile IPv6 node requires a Home Agent address, a home address, andIPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a MobileIPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the MobileNode. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the MobileNode's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. |
|
| |
| RFC 5027 | Security Preconditions for Session Description Protocol (SDP) Media Streams |
| |
|
|
This document defines a new security precondition for the SessionDescription Protocol (SDP) precondition framework described in RFCs3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. |
|
| |
| RFC 5028 | A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services |
| |
|
|
This document registers a Telephone Number Mapping (ENUM) service forInstant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. |
|
| |
| RFC 5029 | Definition of an IS-IS Link Attribute Sub-TLV |
| |
| Authors: | JP. Vasseur, S. Previdi. |
| Date: | September 2007 |
| Formats: | txt html json |
| Updated by: | RFC 9650 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5029 |
|
This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. |
|
| |
| RFC 5030 | Mobile IPv4 RADIUS Requirements |
| |
| Authors: | M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5030 |
|
This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service(RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. |
|
| |
| RFC 5031 | A Uniform Resource Name (URN) for Emergency and Other Well-Known Services |
| |
|
|
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. |
|
| |
| RFC 5032 | WITHIN Search Extension to the IMAP Protocol |
| |
|
|
This document describes the WITHIN extension to IMAP SEARCH. IMAPSEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. |
|
| |
| RFC 5033 | Specifying New Congestion Control Algorithms |
| |
|
|
The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. |
|
| |
| RFC 5034 | The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism |
| |
|
|
This document defines a profile of the Simple Authentication andSecurity Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.
This document seeks to consolidate the information related to POP3AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained inSection 6.3 of RFC 2449. |
|
| |
| RFC 5035 | Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility |
| |
|
|
In the original Enhanced Security Services for S/MIME document (RFC2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. |
|
| |
| RFC 5036 | LDP Specification |
| |
|
|
The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 5037 | Experience with the Label Distribution Protocol (LDP) |
| |
| Authors: | L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5037 |
|
The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. |
|
| |
| RFC 5038 | The Label Distribution Protocol (LDP) Implementation Survey Results |
| |
| Authors: | B. Thomas, L. Andersson. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5038 |
|
Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers(LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label DistributionProtocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, calledLDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey ofLDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. |
|
| |
| RFC 5039 | The Session Initiation Protocol (SIP) and Spam |
| |
| Authors: | J. Rosenberg, C. Jennings. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5039 |
|
Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email.It can affect any system that enables user-to-user communications.The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. |
|
| |
| RFC 5040 | A Remote Direct Memory Access Protocol Specification |
| |
| Authors: | R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5040 |
|
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol(ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. |
|
| |
| RFC 5041 | Direct Data Placement over Reliable Transports |
| |
| Authors: | H. Shah, J. Pinkerton, R. Recio, P. Culley. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5041 |
|
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. |
|
| |
| RFC 5042 | Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security |
| |
| Authors: | J. Pinkerton, E. Deleganes. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5042 |
|
This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct MemoryAccess Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP orRDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from LocalPeers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. |
|
| |
| RFC 5043 | Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation |
| |
|
|
This document specifies an adaptation layer to provide a Lower LayerProtocol (LLP) service for Direct Data Placement (DDP) using theStream Control Transmission Protocol (SCTP). |
|
| |
| RFC 5044 | Marker PDU Aligned Framing for TCP Specification |
| |
| Authors: | P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 6581, RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5044 |
|
Marker PDU Aligned Framing (MPA) is designed to work as an"adaptation layer" between TCP and the Direct Data Placement protocol(DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. |
|
| |
| RFC 5045 | Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) |
| |
| Authors: | C. Bestler, Ed., L. Coene. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5045 |
|
This document describes the applicability of Remote Direct MemoryAccess Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. |
|
| |
| RFC 5046 | Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) |
| |
| Authors: | M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7145 |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5046 |
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. |
|
| |
| RFC 5047 | DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5047 |
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specificDatamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and theDatamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access(RDMA)-capable IP fabrics in the future comprising TCP, the StreamControl Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. |
|
| |
| RFC 5048 | Internet Small Computer System Interface (iSCSI) Corrections and Clarifications |
| |
|
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition inRFC 3720 to serve as a companion document for the iSCSI implementers.This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. |
|
| |
| RFC 5049 | Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updates: | RFC 3486 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5049 |
|
This document describes some specifics that apply when SignalingCompression (SigComp) is applied to the Session Initiation Protocol(SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp overTCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP andSession Description Protocol (SDP) static dictionary. |
|
| |
| RFC 5050 | Bundle Protocol Specification |
| |
| Authors: | K. Scott, S. Burleigh. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5050 |
|
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
This document was produced within the IRTF's Delay TolerantNetworking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. |
|
| |
| RFC 5051 | i;unicode-casemap - Simple Unicode Collation Algorithm |
| |
| Authors: | M. Crispin. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5051 |
|
This document describes "i;unicode-casemap", a simple case- insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. |
|
| |
| RFC 5052 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Watson, M. Luby, L. Vicisano. |
| Date: | August 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 3452 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5052 |
|
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) inReliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. |
|
| |
| RFC 5053 | Raptor Forward Error Correction Scheme for Object Delivery |
| |
| Authors: | M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5053 |
|
This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.
Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.
The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. |
|
| |
| RFC 5054 | Using the Secure Remote Password (SRP) Protocol for TLS Authentication |
| |
| Authors: | D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5054 |
|
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. |
|
| |
| RFC 5055 | Server-Based Certificate Validation Protocol (SCVP) |
| |
| Authors: | T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5055 |
|
The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation(e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. |
|
| |
| RFC 5056 | On the Use of Channel Bindings to Secure Channels |
| |
| Authors: | N. Williams. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5056 |
|
The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.
This document discusses and formalizes the concept of channel binding to secure channels. |
|
| |
| RFC 5057 | Multiple Dialog Usages in the Session Initiation Protocol |
| |
| Authors: | R. Sparks. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5057 |
|
Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.
This is an informative document and makes no normative statements of any kind. |
|
| |
| RFC 5058 | Explicit Multicast (Xcast) Concepts and Options |
| |
| Authors: | R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5058 |
|
While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describesXcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. |
|
| |
| RFC 5059 | Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) |
| |
|
|
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol IndependentMulticast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. |
|
| |
| RFC 5060 | Protocol Independent Multicast MIB |
| |
| Authors: | R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5060 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing theProtocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode),BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC2934. |
|
| |
| RFC 5061 | Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration |
| |
| Authors: | R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5061 |
|
A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. StreamControl Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures.This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. |
|
| |
| RFC 5062 | Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures |
| |
| Authors: | R. Stewart, M. Tuexen, G. Camarillo. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5062 |
|
This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC4460). These techniques are included in RFC 4960, which obsoletesRFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC4960. |
|
| |
| RFC 5063 | Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart |
| |
|
|
This document describes extensions to the Resource ReservationProtocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on thePath message last sent by the node being restarted.
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during theRecovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). |
|
| |
| RFC 5064 | The Archived-At Message Header Field |
| |
| Authors: | M. Duerst. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5064 |
|
This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. |
|
| |
| RFC 5065 | Autonomous System Confederations for BGP |
| |
| Authors: | P. Traina, D. McPherson, J. Scudder. |
| Date: | August 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 3065 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 5065 |
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
This document obsoletes RFC 3065. |
|
| |
| RFC 5066 | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
|
This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.This document describes extensions to the Ethernet-like InterfacesMIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004(note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the InterfacesGroup MIB and the Inverted Stack Table MIB modules. |
|
| |
| RFC 5067 | Infrastructure ENUM Requirements |
| |
| Authors: | S. Lind, P. Pfautz. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5067 |
|
This document provides requirements for "infrastructure" or "carrier"ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) |
|
| |
| RFC 5068 | Email Submission Operations: Access and Accountability Requirements |
| |
| Authors: | C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8314 |
| Also: | BCP 0134 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5068 |
|
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet ServiceProviders. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. |
|
| |
| RFC 5069 | Security Threats and Requirements for Emergency Call Marking and Mapping |
| |
| Authors: | T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5069 |
|
This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to UniversalResource Identifiers (URIs) that point to Public Safety AnsweringPoints (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. |
|
| |
| RFC 5070 | The Incident Object Description Exchange Format |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams(CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. |
|
| |
| RFC 5071 | Dynamic Host Configuration Protocol Options Used by PXELINUX |
| |
| Authors: | D. Hankins. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5071 |
|
This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. |
|
| |
| RFC 5072 | IP Version 6 over PPP |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.
It also specifies the conditions for performing Duplicate AddressDetection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.
This document obsoletes RFC 2472. |
|
| |
| RFC 5073 | IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities |
| |
| Authors: | J.P. Vasseur, Ed., J.L. Le Roux, Ed.. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5073 |
|
It is highly desired, in several cases, to take into account TrafficEngineering (TE) node capabilities during Multi Protocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) Traffic EngineeredLabel Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of aPoint-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) andIntermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. |
|
| |
| RFC 5074 | DNSSEC Lookaside Validation (DLV) |
| |
| Authors: | S. Weiler. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5074 |
|
DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSecurity (DNSSEC) trust anchors outside of the DNS delegation chain.It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publishDelegation Signer (DS) records for their children. |
|
| |
| RFC 5075 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | November 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5175 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5075 |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. |
|
| |
| RFC 5076 | ENUM Validation Information Mapping for the Extensible Provisioning Protocol |
| |
| Authors: | B. Hoeneisen. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5076 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on.Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. |
|
| |
| RFC 5077 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
|
|
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. This document obsoletesRFC 4507. |
|
| |
| RFC 5078 | IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline |
| |
|
|
RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in theNomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson(2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. |
|
| |
| RFC 5079 | Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5079 |
|
The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. |
|
| |
| RFC 5080 | Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes |
| |
|
|
This document describes common issues seen in Remote AuthenticationDial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. |
|
| |
| RFC 5081 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
|
|
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. |
|
| |
| RFC 5082 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 3682 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5082 |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC3682. |
|
| |
| RFC 5083 | Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type |
| |
|
|
This document describes an additional content type for theCryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes.All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. |
|
| |
| RFC 5084 | Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5084 |
|
This document specifies the conventions for using the AES-CCM and theAES-GCM authenticated encryption algorithms with the CryptographicMessage Syntax (CMS) authenticated-enveloped-data content type. |
|
| |
| RFC 5085 | Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires |
| |
| Authors: | T. Nadeau, Ed., C. Pignataro, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5085 |
|
This document describes Virtual Circuit Connectivity Verification(VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. |
|
| |
| RFC 5086 | Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) |
| |
| Authors: | A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5086 |
|
This document describes a method for encapsulating structured (NxDS0)Time Division Multiplexed (TDM) signals as pseudowires over packet- switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC4553). |
|
| |
| RFC 5087 | Time Division Multiplexing over IP (TDMoIP) |
| |
| Authors: | Y(J). Stein, R. Shashoua, R. Insler, M. Anavi. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5087 |
|
Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensureTDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. |
|
| |
| RFC 5088 | OSPF Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5088 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within anOSPF area or within the entire OSPF routing domain. |
|
| |
| RFC 5089 | IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5089 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. |
|
| |
| RFC 5090 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | February 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 4590 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5090 |
|
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 5091 | Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems |
| |
|
|
This document describes the algorithms that implement Boneh-Franklin(BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-basedCryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. |
|
| |
| RFC 5092 | IMAP URL Scheme |
| |
|
|
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
This document obsoletes RFC 2192. It also updates RFC 4467. |
|
| |
| RFC 5093 | BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) |
| |
| Authors: | G. Hunt. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5093 |
|
This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre- standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with theSpecification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. |
|
| |
| RFC 5094 | Mobile IPv6 Vendor Specific Option |
| |
| Authors: | V. Devarapalli, A. Patel, K. Leung. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5094 |
|
There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. |
|
| |
| RFC 5095 | Deprecation of Type 0 Routing Headers in IPv6 |
| |
|
|
The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6Type 0 Routing Headers, in light of this security concern. |
|
| |
| RFC 5096 | Mobile IPv6 Experimental Messages |
| |
| Authors: | V. Devarapalli. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5096 |
|
This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to theMobile IPv6 protocol. |
|
| |
| RFC 5097 | MIB for the UDP-Lite protocol |
| |
| Authors: | G. Renker, G. Fairhurst. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5097 |
|
This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resemblesUDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. |
|
| |
| RFC 5098 | Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) |
| |
| Authors: | G. Beacham, S. Kumar, S. Channabasappa. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5098 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
