RFC Abstracts

RFC4196 - The SEED Cipher Algorithm and Its Use with IPsec
This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]
RFC4195 - A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.
RFC4194 - The S Hexdump Format
This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]
RFC4193 - Unique Local IPv6 Unicast Addresses
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]
RFC4192 - Procedures for Renumbering an IPv6 Network without a Flag Day
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.
RFC4191 - Default Router Preferences and More-Specific Routes
This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]
RFC4190 - Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. This memo provides information for the Internet community.
RFC4189 - Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. This memo provides information for the Internet community.
RFC4188 - Definitions of Managed Objects for Bridges
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 MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.
RFC4187 - Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.
RFC4186 - Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.
RFC4185 - National and Local Characters for DNS Top Level Domain (TLD) Names
In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.
RFC4184 - RTP Payload Format for AC-3 Audio
This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]
RFC4183 - A Suggested Scheme for DNS Resolution of Networks and Gateways
This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.
RFC4182 - Removing a Restriction on the use of MPLS Explicit NULL
The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.
RFC4181 - Guidelines for Authors and Reviewers of MIB Documents
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files
This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.
RFC4179 - Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)
This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. This memo provides information for the Internet community.
RFC4178 - The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.
RFC4177 - Architectural Approaches to Multi-homing for IPv6
This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. This memo provides information for the Internet community.
RFC4176 - Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management
This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.
RFC4175 - RTP Payload Format for Uncompressed Video
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]
RFC4174 - The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]
RFC4173 - Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]
RFC4172 - iFCP - A Protocol for Internet Fibre Channel Storage Networking
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]
RFC4171 - Internet Storage Name Service (iSNS)
This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]
RFC4170 - Tunneling Multiplexed Compressed RTP (TCRTP)
This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4169 - Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2
HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.
RFC4168 - The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]
RFC4167 - Graceful OSPF Restart Implementation Report
Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. This memo provides information for the Internet community.
RFC4166 - Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement
This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. This memo provides information for the Internet community.
RFC4165 - Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]
RFC4164 - RObust Header Compression (ROHC): Context Replication for ROHC Profiles
This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]
RFC4163 - RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression
This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. This memo provides information for the Internet community.
RFC4162 - Addition of SEED Cipher Suites to Transport Layer Security (TLS)
This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]
RFC4161 - Guidelines for Optional Services for Internet Fax Gateways
To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.
RFC4160 - Internet Fax Gateway Requirements
To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This memo provides information for the Internet community.
RFC4159 - Deprecation of "ip6.int"
This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4158 - Internet X.509 Public Key Infrastructure: Certification Path Building
This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.
RFC4157 - The prospero URI Scheme
This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.
RFC4156 - The wais URI Scheme
This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.
RFC4155 - The application/mbox Media Type
This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. This memo provides information for the Internet community.
RFC4154 - Voucher Trading System Application Programming Interface (VTS-API)
This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. This memo provides information for the Internet community.
RFC4153 - XML Voucher: Generic Voucher Language
This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.
RFC4152 - A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code
This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). This memo provides information for the Internet community.
RFC4151 - The 'tag' URI Scheme
This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.
RFC4150 - Transport Performance Metrics MIB
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 monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]
RFC4149 - Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms
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 objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]
RFC4148 - IP Performance Metrics (IPPM) Metrics Registry
This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.
RFC4147 - Proposed Changes to the Format of the IANA IPv6 Registry
This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. This memo provides information for the Internet community.