| |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| 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 |
| |
|
|
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 |
| |
|
|
"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) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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" |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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. |
|
