Internet Documents

RFCs 4100 - 4199s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 4101 Writing Protocol Models
 
Authors:E. Rescorla, IAB.
Date:June 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4101
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.
 
RFC 4102 Registration of the text/red MIME Sub-Type
 
Authors:P. Jones.
Date:June 2005
Formats:txt html json
Updated by:RFC 6354
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4102
This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198.
 
RFC 4103 RTP Payload for Text Conversation
 
Authors:G. Hellstrom, P. Jones.
Date:June 2005
Formats:txt html json
Obsoletes:RFC 2793
Updated by:RFC 9071
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4103
This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separateRTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.

 
RFC 4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)
 
Authors:M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.
Date:June 2005
Formats:txt json html
Updates:RFC 3703
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4104
This document defines a number of changes and extensions to thePolicy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC3703) based on the model extensions defined by the Policy CoreInformation Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types.Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703.
 
RFC 4105 Requirements for Inter-Area MPLS Traffic Engineering
 
Authors:J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed..
Date:June 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4105
This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.
 
RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
 
Authors:J. Viega, D. McGrew.
Date:June 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4106
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating SecurityPayload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.
 
RFC 4107 Guidelines for Cryptographic Key Management
 
Authors:S. Bellovin, R. Housley.
Date:June 2005
Formats:txt html json
Also:BCP 0107
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4107
The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions.When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer.
 
RFC 4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
 
Authors:R. Housley.
Date:August 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4108
This document describes the use of the Cryptographic Message Syntax(CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication.Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.
 
RFC 4109 Algorithms for Internet Key Exchange version 1 (IKEv1)
 
Authors:P. Hoffman.
Date:May 2005
Formats:txt json html
Updates:RFC 2409
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4109
The required and suggested algorithms in the original Internet KeyExchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today.
 
RFC 4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
 
Authors:R. Callon, M. Suzuki.
Date:July 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4110
This document provides a framework for Layer 3 Provider-ProvisionedVirtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.
 
RFC 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
 
Authors:L. Fang, Ed..
Date:July 2005
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4111
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements.In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.
 
RFC 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification
 
Authors:D. Eastlake 3rd.
Date:June 2005
Formats:txt html json
Updates:RFC 3106
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4112
Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic CommerceModeling Language (ECML) and is intended to meet the requirements ofRFC 3505.
 
RFC 4113 Management Information Base for the User Datagram Protocol (UDP)
 
Authors:B. Fenner, J. Flick.
Date:June 2005
Formats:txt html json
Obsoletes:RFC 2454, RFC 2013
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4113
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 implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454.
 
RFC 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
 
Authors:S. Hollenbeck.
Date:June 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4114
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers.
 
RFC 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
 
Authors:O. Aboul-Magd, S. Rabie.
Date:July 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4115
This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic.Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.
 
RFC 4116 IPv4 Multihoming Practices and Limitations
 
Authors:J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill.
Date:July 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4116
Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).
 
RFC 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
 
Authors:G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk.
Date:June 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4117
This document describes how to invoke transcoding services usingSession Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.
 
RFC 4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)
 
Authors:L. Yang, P. Zerfos, E. Sadot.
Date:June 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4118
This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzingWireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.
 
RFC 4119 A Presence-based GEOPRIV Location Object Format
 
Authors:J. Peterson.
Date:December 2005
Formats:txt json html
Updated by:RFC 5139, RFC 5491, RFC 7459
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4119
This document describes an object format for carrying geographical information on the Internet. This location object extends thePresence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.
 
RFC 4120 The Kerberos Network Authentication Service (V5)
 
Authors:C. Neuman, T. Yu, S. Hartman, K. Raeburn.
Date:July 2005
Formats:txt json html
Obsoletes:RFC 1510
Updated by:RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4120
This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.
 
RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
 
Authors:L. Zhu, K. Jaganathan, S. Hartman.
Date:July 2005
Formats:txt json html
Updates:RFC 1964
Updated by:RFC 5896, RFC 6112, RFC 6542, RFC 6649, RFC 8062
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4121
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the KerberosVersion 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles.

 
RFC 4122 A Universally Unique IDentifier (UUID) URN Namespace
 
Authors:P. Leach, M. Mealling, R. Salz.
Date:July 2005
Formats:txt html json
Obsoleted by:RFC 9562
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4122
This specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (GloballyUnique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in theApollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.

This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).Information from earlier versions of the DCE specification have been incorporated into this document.

 
RFC 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements
 
Authors:H. Schulzrinne, C. Agboh.
Date:July 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4123
This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function(SIP-H.323 IWF) that will allow the interworking between SIP andH.323.
 
RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
 
Authors:F. Le Faucheur, Ed..
Date:June 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4124
This document specifies the protocol extensions for support ofDiffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior GatewayProtocol (IGP) extensions already defined for existing MPLS TrafficEngineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS TrafficEngineering. These extensions address the requirements for DS-TE spelled out in RFC 3564.
 
RFC 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
 
Authors:F. Le Faucheur, W. Lai.
Date:June 2005
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 4125
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.
 
RFC 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
 
Authors:J. Ash.
Date:June 2005
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 4126
This document complements the Diffserv-aware MPLS Traffic Engineering(DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) BandwidthConstraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting aBandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.
 
RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
 
Authors:F. Le Faucheur, Ed..
Date:June 2005
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 4127
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.
 
RFC 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation
 
Authors:W. Lai.
Date:June 2005
Formats:txt pdf json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4128
"Differentiated Services (Diffserv)-aware MPLS Traffic EngineeringRequirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, theMaximum Allocation and the Russian Dolls, are described therein.This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.
 
RFC 4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol
 
Authors:R. Mukundan, K. Morneault, N. Mangalpally.
Date:September 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4129
This document defines a mechanism for backhauling Digital PrivateNetwork Signaling System 1 (DPNSS 1) and Digital Access SignalingSystem 2 (DASS 2) messages over IP by extending the ISDN UserAdaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network.DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.
 
RFC 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
 
Authors:D. Moberg, R. Drummond.
Date:July 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4130
This document provides an applicability statement (RFC 2026, Section3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the AmericanNational Standards Committee (ANSI) X12 format or the UN ElectronicData Interchange for Administration, Commerce, and Transport(UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
 
RFC 4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus
 
Authors:S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson.
Date:September 2005
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4131
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP) based management of the Baseline PrivacyPlus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable ServiceInterface Specification) compliant Cable Modems and Cable ModemTermination Systems.
 
RFC 4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS)
 
Authors:S. Moriai, A. Kato, M. Kanda.
Date:July 2005
Formats:txt html json
Obsoleted by:RFC 5932
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4132
This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm.
 
RFC 4133 Entity MIB (Version 3)
 
Authors:A. Bierman, K. McCloghrie.
Date:August 2005
Formats:txt html json
Obsoletes:RFC 2737
Obsoleted by:RFC 6933
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4133
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737).
 
RFC 4134 Examples of S/MIME Messages
 
Authors:P. Hoffman, Ed..
Date:July 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4134
This document gives examples of message bodies formatted usingS/MIME. Specifically, it has examples of Cryptographic MessageSyntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability forS/MIME and other protocols that rely on CMS.
 
RFC 4135 Goals of Detecting Network Attachment in IPv6
 
Authors:JH. Choi, G. Daley.
Date:August 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4135
When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment(DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.
 
RFC 4136 OSPF Refresh and Flooding Reduction in Stable Topologies
 
Authors:P. Pillay-Esnault.
Date:July 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4136
This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.

Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies.

 
RFC 4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator
 
Authors:J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba.
Date:August 2005
Formats:txt pdf html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4137
This document describes a set of state machines for ExtensibleAuthentication Protocol (EAP) peer, EAP stand-alone authenticator(non-pass-through), EAP backend authenticator (for use onAuthentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.

The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAPSwitch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.

The state machine and associated model are informative only.Implementations may achieve the same results using different methods.

 
RFC 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
 
Authors:P. Sarolahti, M. Kojo.
Date:August 2005
Formats:txt json html
Updated by:RFC 5682
Status:EXPERIMENTAL
DOI:10.17487/RFC 4138
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. TheF-RTO algorithm can also be applied to the Stream ControlTransmission Protocol (SCTP).
 
RFC 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
 
Authors:D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong.
Date:July 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4139
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, includingSynchronous Optical Network (SONET)/Synchronous Digital Hierarchy(SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by theGMPLS signaling protocol to support the capabilities of anAutomatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for theGMPLS signaling protocol to support the ASON functionality.

 
RFC 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
 
Authors:H. Soliman, C. Castelluccia, K. El Malki, L. Bellier.
Date:August 2005
Formats:txt html json
Obsoleted by:RFC 5380
Status:EXPERIMENTAL
DOI:10.17487/RFC 4140
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
 
RFC 4141 SMTP and MIME Extensions for Content Conversion
 
Authors:K. Toyoda, D. Crocker.
Date:November 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4141
A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information(e.g., changing from color to black and white). In a store-and- forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates twoESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries.
 
RFC 4142 Full-mode Fax Profile for Internet Mail (FFPIM)
 
Authors:D. Crocker, G. Klyne.
Date:November 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4142
Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.
 
RFC 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM
 
Authors:K. Toyoda, D. Crocker.
Date:November 2005
Formats:txt json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4143
This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.IFax is "facsimile using Internet mail". For this use, the DomainName System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address.
 
RFC 4144 How to Gain Prominence and Influence in Standards Organizations
 
Authors:D. Eastlake 3rd.
Date:September 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4144
This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations.
 
RFC 4145 TCP-Based Media Transport in the Session Description Protocol (SDP)
 
Authors:D. Yon, G. Camarillo.
Date:September 2005
Formats:txt html json
Updated by:RFC 4572
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4145
This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment.
 
RFC 4146 Simple New Mail Notification
 
Authors:R. Gellens.
Date:August 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4146
This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail.

 
RFC 4147 Proposed Changes to the Format of the IANA IPv6 Registry
 
Authors:G. Huston.
Date:August 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4147
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.
 
RFC 4148 IP Performance Metrics (IPPM) Metrics Registry
 
Authors:E. Stephan.
Date:August 2005
Formats:txt html json
Obsoleted by:RFC 6248
Also:BCP 0108
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4148
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.

This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.

IANA has been assigned to administer this new registry.

 
RFC 4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms
 
Authors:C. Kalbfleisch, R. Cole, D. Romascanu.
Date:August 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4149
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.
 
RFC 4150 Transport Performance Metrics MIB
 
Authors:R. Dietz, R. Cole.
Date:August 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4150
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.
 
RFC 4151 The 'tag' URI Scheme
 
Authors:T. Kindberg, S. Hawke.
Date:October 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4151
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.
 
RFC 4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code
 
Authors:K. Tesink, R. Fox.
Date:August 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4152
This document describes a Uniform Resource Name (URN) namespace(RFC 3406) for the assignment of the Common Language EquipmentIdentifier (CLEI) code, which is used in messages standardized byANSI. 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. TheCLEI 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).
 
RFC 4153 XML Voucher: Generic Voucher Language
 
Authors:K. Fujimura, M. Terada, D. Eastlake 3rd.
Date:September 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4153
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.
 
RFC 4154 Voucher Trading System Application Programming Interface (VTS-API)
 
Authors:M. Terada, K. Fujimura.
Date:September 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4154
This document specifies the Voucher Trading System ApplicationProgramming 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.
 
RFC 4155 The application/mbox Media Type
 
Authors:E. Hall.
Date:September 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4155
This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.
 
RFC 4156 The wais URI Scheme
 
Authors:P. Hoffman.
Date:August 2005
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 4156
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.
 
RFC 4157 The prospero URI Scheme
 
Authors:P. Hoffman.
Date:August 2005
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 4157
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.
 
RFC 4158 Internet X.509 Public Key Infrastructure: Certification Path Building
 
Authors:M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas.
Date:September 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4158
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.
 
RFC 4159 Deprecation of "ip6.int"
 
Authors:G. Huston.
Date:August 2005
Formats:txt html json
Also:BCP 0109
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4159
This document advises of the deprecation of the use of "ip6.int" forStandards Conformant IPv6 implementations.
 
RFC 4160 Internet Fax Gateway Requirements
 
Authors:K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio.
Date:August 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4160
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 FaxGateways. 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.
 
RFC 4161 Guidelines for Optional Services for Internet Fax Gateways
 
Authors:K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide.
Date:August 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4161
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 ofInternet 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.

This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.

 
RFC 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS)
 
Authors:H.J. Lee, J.H. Yoon, J.I. Lee.
Date:August 2005
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4162
This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm.
 
RFC 4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression
 
Authors:L-E. Jonsson.
Date:August 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4163
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.
 
RFC 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles
 
Authors:G. Pelletier.
Date:August 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4164
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.
 
RFC 4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
 
Authors:T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault.
Date:September 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4165
This document defines a protocol supporting the transport ofSignaling 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 theSS7 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.
 
RFC 4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement
 
Authors:L. Coene, J. Pastor-Balbas.
Date:February 2006
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4166
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 TransmissionProtocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.
 
RFC 4167 Graceful OSPF Restart Implementation Report
 
Authors:A. Lindem.
Date:October 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4167
Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol.
 
RFC 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg, H. Schulzrinne, G. Camarillo.
Date:October 2005
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4168
This document specifies a mechanism for usage of SCTP (the StreamControl 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.
 
RFC 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2
 
Authors:V. Torvinen, J. Arkko, M. Naslund.
Date:November 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4169
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.
 
RFC 4170 Tunneling Multiplexed Compressed RTP (TCRTP)
 
Authors:B. Thompson, T. Koren, D. Wing.
Date:November 2005
Formats:txt html json
Also:BCP 0110
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4170
This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-timeTransport 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.
 
RFC 4171 Internet Storage Name Service (iSNS)
 
Authors:J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza.
Date:September 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4171
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 andFibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.
 
RFC 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking
 
Authors:C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards.
Date:September 2005
Formats:txt json html
Updated by:RFC 6172, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4172
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.
 
RFC 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
 
Authors:P. Sarkar, D. Missimer, C. Sapuntzakis.
Date:September 2005
Formats:txt json html
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4173
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.
 
RFC 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
 
Authors:C. Monia, J. Tseng, K. Gibbons.
Date:September 2005
Formats:txt html json
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4174
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 ChannelProtocol (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.
 
RFC 4175 RTP Payload Format for Uncompressed Video
 
Authors:L. Gharai, C. Perkins.
Date:September 2005
Formats:txt html json
Updated by:RFC 4421
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4175
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time TransportProtocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITUBT.601, and standards from the Society of Motion Picture andTelevision 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.
 
RFC 4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management
 
Authors:Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet.
Date:October 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4176
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.
 
RFC 4177 Architectural Approaches to Multi-homing for IPv6
 
Authors:G. Huston.
Date:September 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4177
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.
 
RFC 4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
 
Authors:L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll.
Date:October 2005
Formats:txt html json
Obsoletes:RFC 2478
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4178
This document specifies a negotiation mechanism for the GenericSecurity 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.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet.

 
RFC 4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)
 
Authors:S. Kang.
Date:October 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4179
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.
 
RFC 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files
 
Authors:Y. Shafranovich.
Date:October 2005
Formats:txt html json
Updated by:RFC 7111
Status:INFORMATIONAL
DOI:10.17487/RFC 4180
This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".
 
RFC 4181 Guidelines for Authors and Reviewers of MIB Documents
 
Authors:C. Heard, Ed..
Date:September 2005
Formats:txt html json
Updated by:RFC 4841
Also:BCP 0111
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4181
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.
 
RFC 4182 Removing a Restriction on the use of MPLS Explicit NULL
 
Authors:E. Rosen.
Date:September 2005
Formats:txt json html
Updates:RFC 3032
Updated by:RFC 5462, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4182
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 theMPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032.

 
RFC 4183 A Suggested Scheme for DNS Resolution of Networks and Gateways
 
Authors:E. Warnicke.
Date:September 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4183
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.
 
RFC 4184 RTP Payload Format for AC-3 Audio
 
Authors:B. Link, T. Hager, J. Flaks.
Date:October 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4184
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 UnitedStates HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.
 
RFC 4185 National and Local Characters for DNS Top Level Domain (TLD) Names
 
Authors:J. Klensin.
Date:October 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4185
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.
 
RFC 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
 
Authors:H. Haverinen, Ed., J. Salowey, Ed..
Date:January 2006
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4186
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using theGlobal System for Mobile Communications (GSM) Subscriber IdentityModule (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.
 
RFC 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
 
Authors:J. Arkko, H. Haverinen.
Date:January 2006
Formats:txt json html
Updated by:RFC 5448, RFC 9048
Status:INFORMATIONAL
DOI:10.17487/RFC 4187
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 MobileTelecommunications 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.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure.

 
RFC 4188 Definitions of Managed Objects for Bridges
 
Authors:K. Norseth, Ed., E. Bell, Ed..
Date:September 2005
Formats:txt html json
Obsoletes:RFC 1493
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4188
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.

The MIB module presented in this memo is a translation of theBRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.

This memo obsoletes RFC 1493.

 
RFC 4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
 
Authors:K. Ono, S. Tachimoto.
Date:October 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4189
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.
 
RFC 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
 
Authors:K. Carlberg, I. Brown, C. Beard.
Date:November 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4190
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 EmergencyTelecommunications Service (ETS), should be realized within today'sIP 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 existingIETF 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.
 
RFC 4191 Default Router Preferences and More-Specific Routes
 
Authors:R. Draves, D. Thaler.
Date:November 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4191
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.
 
RFC 4192 Procedures for Renumbering an IPv6 Network without a Flag Day
 
Authors:F. Baker, E. Lear, R. Droms.
Date:September 2005
Formats:txt json html
Updates:RFC 2072
Status:INFORMATIONAL
DOI:10.17487/RFC 4192
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.
 
RFC 4193 Unique Local IPv6 Unicast Addresses
 
Authors:R. Hinden, B. Haberman.
Date:October 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4193
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 globalInternet.
 
RFC 4194 The S Hexdump Format
 
Authors:J. Strombergson, L. Walleij, P. Faltstrom.
Date:October 2005
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4194
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.
 
RFC 4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
 
Authors:W. Kameyama.
Date:October 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4195
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 ForumStandards, XML (Extensible Markup Language) Document TypeDefinitions, XML Schemas, Namespaces, and other documents.
 
RFC 4196 The SEED Cipher Algorithm and Its Use with IPsec
 
Authors:H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee.
Date:October 2005
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4196
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 IPsecEncapsulating Security Payload (ESP).
 
RFC 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
 
Authors:M. Riegel, Ed..
Date:October 2005
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 4197
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.
 
RFC 4198 A Uniform Resource Name (URN) Namespace for Federated Content
 
Authors:D. Tessman.
Date:November 2005
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 4198
This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members.