| |
| RFC 4401 | A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) |
| |
| Authors: | N. Williams. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4401 |
|
This document defines a Pseudo-Random Function (PRF) extension to theGeneric Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. |
|
| |
| RFC 4402 | A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism |
| |
|
|
This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. |
|
| |
| RFC 4403 | Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) |
| |
| Authors: | B. Bergeson, K. Boogert, V. Nanjundaswamy. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4403 |
|
This document defines the Lightweight Directory Access Protocol(LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. |
|
| |
| RFC 4404 | Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) |
| |
| Authors: | R. Natarajan, A. Rijhsinghani. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4404 |
|
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 Fibre Channel OverTCP/IP (FCIP) entities, which are used to interconnect Fibre Channel(FC) fabrics with IP networks. |
|
| |
| RFC 4405 | SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message |
| |
| Authors: | E. Allman, H. Katz. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4405 |
|
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. |
|
| |
| RFC 4406 | Sender ID: Authenticating E-Mail |
| |
| Authors: | J. Lyon, M. Wong. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4406 |
|
Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. |
|
| |
| RFC 4407 | Purported Responsible Address in E-Mail Messages |
| |
|
|
This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA). |
|
| |
| RFC 4408 | Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |
| |
|
|
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. |
|
| |
| RFC 4409 | Message Submission for Mail |
| |
|
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay and final delivery are unaffected, and continue to useSMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
| |
| RFC 4410 | Selectively Reliable Multicast Protocol (SRMP) |
| |
| Authors: | M. Pullen, F. Zhao, D. Cohen. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4410 |
|
The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and aSelectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. |
|
| |
| RFC 4411 | Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events |
| |
| Authors: | J. Polk. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4411 |
|
This document proposes an IANA Registration extension to the SessionInitiation Protocol (SIP) Reason Header to be included in a BYEMethod Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol(RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. |
|
| |
| RFC 4412 | Communications Resource Priority for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Schulzrinne, J. Polk. |
| Date: | February 2006 |
| Formats: | txt json html |
| Updated by: | RFC 7134 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4412 |
|
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely,"Resource-Priority" and "Accept-Resource-Priority". The"Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior ofIP routers. |
|
| |
| RFC 4413 | TCP/IP Field Behavior |
| |
| Authors: | M. West, S. McCann. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4413 |
|
This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. |
|
| |
| RFC 4414 | An ENUM Registry Type for the Internet Registry Information Service (IRIS) |
| |
| Authors: | A. Newton. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4414 |
|
This document describes an Internet Registry Information Service(IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. |
|
| |
| RFC 4415 | IANA Registration for Enumservice Voice |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4415 |
|
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in theENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. |
|
| |
| RFC 4416 | Goals for Internet Messaging to Support Diverse Service Environments |
| |
| Authors: | J. Wong, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4416 |
|
This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements toInternet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.
The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments-- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.
The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. |
|
| |
| RFC 4417 | Report of the 2004 IAB Messaging Workshop |
| |
| Authors: | P. Resnick, Ed., P. Saint-Andre, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4417 |
|
This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. |
|
| |
| RFC 4418 | UMAC: Message Authentication Code using Universal Hashing |
| |
| Authors: | T. Krovetz, Ed.. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4418 |
|
This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors.Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.
To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. |
|
| |
| RFC 4419 | Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol |
| |
| Authors: | M. Friedl, N. Provos, W. Simpson. |
| Date: | March 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8270 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4419 |
|
This memo describes a new key exchange method for the Secure Shell(SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. |
|
| |
| RFC 4420 | Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs. |
|
| |
| RFC 4421 | RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes |
| |
|
|
The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes. |
|
| |
| RFC 4422 | Simple Authentication and Security Layer (SASL) |
| |
| Authors: | A. Melnikov, Ed., K. Zeilenga, Ed.. |
| Date: | June 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2222 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4422 |
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms.The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms.The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.
This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 2222. |
|
| |
| RFC 4423 | Host Identity Protocol (HIP) Architecture |
| |
| Authors: | R. Moskowitz, P. Nikander. |
| Date: | May 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9063 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4423 |
|
This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, theHost Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since.This document represents one stable point in that evolution of understanding. |
|
| |
| RFC 4424 | Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec |
| |
|
|
This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e.,VMR-WB mode 4). These updates do not affect the existing modes ofVMR-WB already specified in RFC 4348.
The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. |
|
| |
| RFC 4425 | RTP Payload Format for Video Codec 1 (VC-1) |
| |
| Authors: | A. Klemets. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4425 |
|
This memo specifies an RTP payload format for encapsulating VideoCodec 1 (VC-1) compressed bit streams, as defined by the Society ofMotion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. |
|
| |
| RFC 4426 | Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification |
| |
| Authors: | J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed.. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4426 |
|
This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol LabelSwitching (GMPLS)-based recovery (i.e., protection and restoration).Protocol specific formats and mechanisms will be described in companion documents. |
|
| |
| RFC 4427 | Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) |
| |
| Authors: | E. Mannie, Ed., D. Papadimitriou, Ed.. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4427 |
|
This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. |
|
| |
| RFC 4428 | Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) |
| |
| Authors: | D. Papadimitriou, Ed., E. Mannie, Ed.. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4428 |
|
This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. |
|
| |
| RFC 4429 | Optimistic Duplicate Address Detection (DAD) for IPv6 |
| |
|
|
Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) andStateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. |
|
| |
| RFC 4430 | Kerberized Internet Negotiation of Keys (KINK) |
| |
| Authors: | S. Sakane, K. Kamada, M. Thomas, J. Vilhuber. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4430 |
|
This document describes the Kerberized Internet Negotiation of Keys(KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of theInternet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. |
|
| |
| RFC 4431 | The DNSSEC Lookaside Validation (DLV) DNS Resource Record |
| |
| Authors: | M. Andrews, S. Weiler. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4431 |
|
This document defines a new DNS resource record, called the DNSSECLookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. |
|
| |
| RFC 4432 | RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. |
|
| |
| RFC 4433 | Mobile IPv4 Dynamic Home Agent (HA) Assignment |
| |
| Authors: | M. Kulkarni, A. Patel, K. Leung. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4433 |
|
Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a MobileIP session while allowing any suitable method for HA selection. |
|
| |
| RFC 4434 | The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
|
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, calledAES-XCBC-PRF-128. |
|
| |
| RFC 4435 | A Framework for the Usage of Internet Media Guides (IMGs) |
| |
| Authors: | Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4435 |
|
This document defines a framework for the delivery of Internet MediaGuides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol(SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. |
|
| |
| RFC 4436 | Detecting Network Attachment in IPv4 (DNAv4) |
| |
| Authors: | B. Aboba, J. Carlson, S. Cheshire. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4436 |
|
The time required to detect movement between networks and to obtain(or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment forIPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. |
|
| |
| RFC 4437 | Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources |
| |
| Authors: | J. Whitehead, G. Clemm, J. Reschke, Ed.. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4437 |
|
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx(Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. |
|
| |
| RFC 4438 | Fibre-Channel Name Server MIB |
| |
| Authors: | C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4438 |
|
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 for information related to the Name Server function of a Fibre Channel network. The FibreChannel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. |
|
| |
| RFC 4439 | Fibre Channel Fabric Address Manager MIB |
| |
| Authors: | C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4439 |
|
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 for information related to a Fibre Channel network's Fabric Address Manager. |
|
| |
| RFC 4440 | IAB Thoughts on the Role of the Internet Research Task Force (IRTF) |
| |
| Authors: | S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4440 |
|
This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of theIRTF. |
|
| |
| RFC 4441 | The IEEE 802/IETF Relationship |
| |
|
|
Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs andAuthentication, Authorization, and Accounting (AAA) applications.This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. |
|
| |
| RFC 4442 | Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) |
| |
| Authors: | S. Fries, H. Tschofenig. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4442 |
|
TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios.TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized inTESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios whereSRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
This document specifies payloads for the Multimedia Internet Keying(MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. |
|
| |
| RFC 4443 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
|
|
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is theInternet Control Message Protocol for Internet Protocol version 6(IPv6). |
|
| |
| RFC 4444 | Management Information Base for Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | J. Parker, Ed.. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4444 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.Specifically, this document describes a MIB for the IntermediateSystem to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. |
|
| |
| RFC 4445 | A Proposed Media Delivery Index (MDI) |
| |
| Authors: | J. Welch, J. Clark. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4445 |
|
This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media,MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.
The MDI measurement defined in this memo is intended for Information only. |
|
| |
| RFC 4446 | IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) |
| |
|
|
This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in thePseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. |
|
| |
| RFC 4447 | Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) |
| |
|
|
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. |
|
| |
| RFC 4448 | Encapsulation Methods for Transport of Ethernet over MPLS Networks |
| |
|
|
An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 ProtocolData Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation ofEthernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. |
|
| |
| RFC 4449 | Securing Mobile IPv6 Route Optimization Using a Static Shared Key |
| |
| Authors: | C. Perkins. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4449 |
|
A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. |
|
| |
| RFC 4450 | Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents |
| |
| Authors: | E. Lear, H. Alvestrand. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4450 |
|
This memo documents an experiment to review and classify ProposedStandards as not reflecting documented practice within the world today. The results identify a set of documents that were marked asProposed Standards that are now reclassified as Historic. |
|
| |
| RFC 4451 | BGP MULTI_EXIT_DISC (MED) Considerations |
| |
| Authors: | D. McPherson, V. Gill. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4451 |
|
The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.
This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. |
|
| |
| RFC 4452 | The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces |
| |
| Authors: | H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4452 |
|
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.Namespaces participating in the "info" URI scheme are regulated by an"info" Registry mechanism. |
|
| |
| RFC 4453 | Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, G. Camarillo, Ed., D. Willis. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4453 |
|
The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks.This document identifies a set of requirements for extensions to SIP that add consent-based communications. |
|
| |
| RFC 4454 | Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | S. Singh, M. Townsley, C. Pignataro. |
| Date: | May 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4454 |
|
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use theL2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over anIP network. |
|
| |
| RFC 4455 | Definition of Managed Objects for Small Computer System Interface (SCSI) Entities |
| |
| Authors: | M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4455 |
|
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 for Small Computer SystemInterface (SCSI) entities, independently of the interconnect subsystem layer. |
|
| |
| RFC 4456 | BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) |
| |
|
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.
This document describes the use and design of a method known as"route reflection" to alleviate the need for "full mesh" Internal BGP(IBGP).
This document obsoletes RFC 2796 and RFC 1966. |
|
| |
| RFC 4457 | The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) |
| |
| Authors: | G. Camarillo, G. Blanco. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4457 |
|
This document specifies the Session Initiation Protocol (SIP)P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. |
|
| |
| RFC 4458 | Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) |
| |
| Authors: | C. Jennings, F. Audet, J. Elwell. |
| Date: | April 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8119 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4458 |
|
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. |
|
| |
| RFC 4459 | MTU and Fragmentation Issues with In-the-Network Tunneling |
| |
| Authors: | P. Savola. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4459 |
|
Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. |
|
| |
| RFC 4460 | Stream Control Transmission Protocol (SCTP) Specification Errata and Issues |
| |
| Authors: | R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. |
| Date: | April 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4460 |
|
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied.In addition to the delta, a description of the problem and the details of the solution are also provided. |
|
| |
| RFC 4461 | Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) |
| |
| Authors: | S. Yasukawa, Ed.. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4461 |
|
This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE)Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
There is no intent to specify solution-specific details or application-specific requirements in this document.
The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), TimeDivision Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. |
|
| |
| RFC 4462 | Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol |
| |
|
|
The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.
This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. |
|
| |
| RFC 4463 | A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks |
| |
| Authors: | S. Shanmugham, P. Monaco, B. Eberman. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4463 |
|
This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for furtherIETF development in this area.
MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (SessionInitiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms likeRTP (Real Time Protocol). |
|
| |
| RFC 4464 | Signaling Compression (SigComp) Users' Guide |
| |
| Authors: | A. Surtees, M. West. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4464 |
|
This document provides an informational guide for users of theSignaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. |
|
| |
| RFC 4465 | Signaling Compression (SigComp) Torture Tests |
| |
| Authors: | A. Surtees, M. West. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4465 |
|
This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. |
|
| |
| RFC 4466 | Collected Extensions to IMAP4 ABNF |
| |
|
|
Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.
This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined inRFC 3501. The patterns provide for compatibility between existing and future extensions.
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. |
|
| |
| RFC 4467 | Internet Message Access Protocol (IMAP) - URLAUTH Extension |
| |
|
|
This document describes the URLAUTH extension to the Internet MessageAccess Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)(RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.
An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". |
|
| |
| RFC 4468 | Message Submission BURL Extension |
| |
|
|
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. |
|
| |
| RFC 4469 | Internet Message Access Protocol (IMAP) CATENATE Extension |
| |
|
|
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on theIMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. |
|
| |
| RFC 4470 | Minimally Covering NSEC Records and DNSSEC On-line Signing |
| |
|
|
This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. |
|
| |
| RFC 4471 | Derivation of DNS Name Predecessor and Successor |
| |
| Authors: | G. Sisson, B. Laurie. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4471 |
|
This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. |
|
| |
| RFC 4472 | Operational Considerations and Issues with IPv6 DNS |
| |
| Authors: | A. Durand, J. Ihren, P. Savola. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4472 |
|
This memo presents operational considerations and issues with IPv6Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. |
|
| |
| RFC 4473 | Requirements for Internet Media Guides (IMGs) |
| |
| Authors: | Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4473 |
|
This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. |
|
| |
| RFC 4474 | Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, C. Jennings. |
| Date: | August 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8224 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4474 |
|
The existing security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. |
|
| |
| RFC 4475 | Session Initiation Protocol (SIP) Torture Test Messages |
| |
| Authors: | R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4475 |
|
This informational document gives examples of Session InitiationProtocol (SIP) test messages designed to exercise and "torture" a SIP implementation. |
|
| |
| RFC 4476 | Attribute Certificate (AC) Policies Extension |
| |
| Authors: | C. Francis, D. Pinkas. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4476 |
|
This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specificACPs. |
|
| |
| RFC 4477 | Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues |
| |
| Authors: | T. Chown, S. Venaas, C. Strauf. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4477 |
|
A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol(DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. |
|
| |
| RFC 4478 | Repeated Authentication in Internet Key Exchange (IKEv2) Protocol |
| |
| Authors: | Y. Nir. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4478 |
|
This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. |
|
| |
| RFC 4479 | A Data Model for Presence |
| |
| Authors: | J. Rosenberg. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4479 |
|
This document defines the underlying presence data model used bySession Initiation Protocol (SIP) for Instant Messaging and PresenceLeveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. |
|
| |
| RFC 4480 | RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) |
| |
| Authors: | H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4480 |
|
The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication.The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence InformationData Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.
This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.
These extensions include presence information for persons, services(tuples), and devices. |
|
| |
| RFC 4481 | Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals |
| |
| Authors: | H. Schulzrinne. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4481 |
|
The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension(<timed-status&rt; element) that allows a presentity to declare its status for a time interval fully in the future or the past. |
|
| |
| RFC 4482 | CIPID: Contact Information for the Presence Information Data Format |
| |
| Authors: | H. Schulzrinne. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4482 |
|
The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. TheContact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. |
|
| |
| RFC 4483 | A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages |
| |
| Authors: | E. Burger, Ed.. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4483 |
|
This document defines an extension to the URL MIME External-BodyAccess-Type to satisfy the content indirection requirements for theSession Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. |
|
| |
| RFC 4484 | Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, J. Polk, D. Sicker, H. Tschofenig. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4484 |
|
This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. |
|
| |
| RFC 4485 | Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4485 |
|
The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across theInternet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. |
|
| |
| RFC 4486 | Subcodes for BGP Cease Notification Message |
| |
|
|
This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. |
|
| |
| RFC 4487 | Mobile IPv6 and Firewalls: Problem Statement |
| |
| Authors: | F. Le, S. Faccin, B. Patil, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4487 |
|
This document captures the issues that may arise in the deployment ofIPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such asGeneral Packet Radio Service / Universal Mobile TelecommunicationsSystem (GPRS/UMTS) and CDMA2000 networks.
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. |
|
| |
| RFC 4488 | Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription |
| |
| Authors: | O. Levin. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4488 |
|
The Session Initiation Protocol (SIP) REFER extension as defined inRFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by theREFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. |
|
| |
| RFC 4489 | A Method for Generating Link-Scoped IPv6 Multicast Addresses |
| |
| Authors: | J-S. Park, M-K. Shin, H-J. Kim. |
| Date: | April 2006 |
| Formats: | txt json html |
| Updates: | RFC 3306 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4489 |
|
This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use ofInterface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast- prefix-based IPv6 multicast addresses. This memo updates RFC 3306. |
|
| |
| RFC 4490 | Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Leontiev, Ed., G. Chudov, Ed.. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4490 |
|
This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, andGOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. |
|
| |
| RFC 4491 | Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
| |
| Authors: | S. Leontiev, Ed., D. Shefanovski, Ed.. |
| Date: | May 2006 |
| Formats: | txt json html |
| Updates: | RFC 3279 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4491 |
|
This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509Public Key Infrastructure (PKI). |
|
| |
| RFC 4492 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. |
|
| |
| RFC 4493 | The AES-CMAC Algorithm |
| |
| Authors: | JH. Song, R. Poovendran, J. Lee, T. Iwata. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4493 |
|
The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard(AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. |
|
| |
| RFC 4494 | The AES-CMAC-96 Algorithm and Its Use with IPsec |
| |
| Authors: | JH. Song, R. Poovendran, J. Lee. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4494 |
|
The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode on the authentication mechanism of theIPsec Encapsulating Security Payload (ESP) and the AuthenticationHeader (AH) protocols. This new algorithm is named AES-CMAC-96. |
|
| |
| RFC 4495 | A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow |
| |
|
|
This document proposes an extension to the Resource ReservationProtocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms ofRSVP tunnels. This specification is an extension of RFC 2205. |
|
| |
| RFC 4496 | Open Pluggable Edge Services (OPES) SMTP Use Cases |
| |
| Authors: | M. Stecher, A. Barbir. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4496 |
|
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. |
|
| |
| RFC 4497 | Interworking between the Session Initiation Protocol (SIP) and QSIG |
| |
|
|
This document specifies interworking between the Session InitiationProtocol (SIP) and QSIG within corporate telecommunication networks(also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) withinPrivate Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. |
|
| |
| RFC 4498 | The Managed Object Aggregation MIB |
| |
| Authors: | G. Keeni. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4498 |
|
This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the AggregationMIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated ManagedObject instances. |
|
