| |
| RFC 4301 | Security Architecture for the Internet Protocol |
| |
|
|
This document describes an updated version of the "SecurityArchitecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401(November 1998). |
|
| |
| RFC 4302 | IP Authentication Header |
| |
|
|
This document describes an updated version of the IP AuthenticationHeader (AH), which is designed to provide authentication services inIPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). |
|
| |
| RFC 4303 | IP Encapsulating Security Payload (ESP) |
| |
|
|
This document describes an updated version of the EncapsulatingSecurity Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). |
|
| |
| RFC 4304 | Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) |
| |
| Authors: | S. Kent. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4304 |
|
The IP Security Authentication Header (AH) and Encapsulating SecurityPayload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain ofInterpretation (DOI) for the Internet Security Association and KeyManagement Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64- bit) sequence numbers (ESNs) for a particular AH or ESP security association. |
|
| |
| RFC 4305 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4306 | Internet Key Exchange (IKEv2) Protocol |
| |
|
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations(SAs).
This version of the IKE specification combines the contents of what were previously separate documents, including Internet SecurityAssociation and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC2409), the Internet Domain of Interpretation (DOI, RFC 2407), NetworkAddress Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. |
|
| |
| RFC 4307 | Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4308 | Cryptographic Suites for IPsec |
| |
| Authors: | P. Hoffman. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4308 |
|
The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. |
|
| |
| RFC 4309 | Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) |
| |
| Authors: | R. Housley. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4309 |
|
This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. |
|
| |
| RFC 4310 | Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security extensions (DNSSEC) for 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 DNS security extensions. |
|
| |
| RFC 4311 | IPv6 Host-to-Router Load Sharing |
| |
|
|
The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. |
|
| |
| RFC 4312 | The Camellia Cipher Algorithm and Its Use With IPsec |
| |
| Authors: | A. Kato, S. Moriai, M. Kanda. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4312 |
|
This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicitInitialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). |
|
| |
| RFC 4313 | Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources |
| |
| Authors: | D. Oran. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4313 |
|
This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and RealTime Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. |
|
| |
| RFC 4314 | IMAP4 Access Control List (ACL) Extension |
| |
|
|
The Access Control List (ACL) extension (RFC 2086) of the InternetMessage Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.
This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. |
|
| |
| RFC 4315 | Internet Message Access Protocol (IMAP) - UIDPLUS extension |
| |
|
|
The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. |
|
| |
| RFC 4316 | Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties |
| |
| Authors: | J. Reschke. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4316 |
|
This specification extends the Web Distributed Authoring andVersioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. |
|
| |
| RFC 4317 | Session Description Protocol (SDP) Offer/Answer Examples |
| |
| Authors: | A. Johnston, R. Sparks. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4317 |
|
This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. CommonThird Party Call Control (3pcc) examples are also given. |
|
| |
| RFC 4318 | Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol |
| |
| Authors: | D. Levi, D. Harrington. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4318 |
|
This memo defines an SMIv2 MIB module for managing the Rapid SpanningTree capability defined by the IEEE P802.1t and P802.1w amendments toIEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. |
|
| |
| RFC 4319 | Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines |
| |
| Authors: | C. Sikes, B. Ray, R. Abbi. |
| Date: | December 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 3276 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4319 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-RateDigital Subscriber Line (DSL) - 2nd generation (HDSL2) andSingle-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. |
|
| |
| RFC 4320 | Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction |
| |
|
|
This document describes modifications to the Session InitiationProtocol (SIP) to address problems that have been identified with theSIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding.These changes update behavior defined in RFC 3261. |
|
| |
| RFC 4321 | Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction |
| |
| Authors: | R. Sparks. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4321 |
|
This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. |
|
| |
| RFC 4322 | Opportunistic Encryption using the Internet Key Exchange (IKE) |
| |
| Authors: | M. Richardson, D.H. Redelmeier. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4322 |
|
This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet KeyExchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. |
|
| |
| RFC 4323 | Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) |
| |
| Authors: | M. Patrick, W. Murwin. |
| Date: | January 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4323 |
|
This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and CableModem Termination Systems (CMTSs) conforming to the Data over CableSystem (DOCSIS) specifications versions 1.1 and 2.0. |
|
| |
| RFC 4324 | Calendar Access Protocol (CAP) |
| |
| Authors: | D. Royer, G. Babics, S. Mansour. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4324 |
|
The Calendar Access Protocol (CAP) described in this memo permits aCalendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. |
|
| |
| RFC 4325 | Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension |
| |
|
|
This document updates RFC 3280 by defining the Authority InformationAccess Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. |
|
| |
| RFC 4326 | Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) |
| |
| Authors: | G. Fairhurst, B. Collini-Nocker. |
| Date: | December 2005 |
| Formats: | txt html json |
| Updated by: | RFC 7280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4326 |
|
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.
This document describes a Unidirectional Lightweight Encapsulation(ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 TransportStream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. |
|
| |
| RFC 4327 | Link Management Protocol (LMP) Management Information Base (MIB) |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. |
| Date: | January 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4631 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4327 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP). |
|
| |
| RFC 4328 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control |
| |
|
|
This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to controlOptical Transport Networks (OTN); it also includes the so-called pre-OTN developments. |
|
| |
| RFC 4329 | Scripting Media Types |
| |
|
|
This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. |
|
| |
| RFC 4330 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP. |
|
| |
| RFC 4331 | Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections |
| |
| Authors: | B. Korver, L. Dusseault. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4331 |
|
Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. |
|
| |
| RFC 4332 | Cisco's Mobile IPv4 Host Configuration Extensions |
| |
| Authors: | K. Leung, A. Patel, G. Tsirtsis, E. Klovning. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4332 |
|
An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host ConfigurationProtocol (DHCP) or Point-to-Point Protocol/IP Control Protocol(PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. |
|
| |
| RFC 4333 | The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process |
| |
| Authors: | G. Huston, Ed., B. Wijnen, Ed.. |
| Date: | December 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8711 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4333 |
|
This memo outlines the guidelines for selection of members of theIETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. |
|
| |
| RFC 4334 | Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
| |
| Authors: | R. Housley, T. Moore. |
| Date: | February 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 3770 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4334 |
|
This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. |
|
| |
| RFC 4335 | The Secure Shell (SSH) Session Channel Break Extension |
| |
| Authors: | J. Galbraith, P. Remaker. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4335 |
|
The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. |
|
| |
| RFC 4336 | Problem Statement for the Datagram Congestion Control Protocol (DCCP) |
| |
| Authors: | S. Floyd, M. Handley, E. Kohler. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4336 |
|
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. |
|
| |
| RFC 4337 | MIME Type Registration for MPEG-4 |
| |
|
|
This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents. |
|
| |
| RFC 4338 | Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel |
| |
|
|
This document specifies the way of encapsulating IPv6, IPv4, andAddress Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on FibreChannel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.
This document obsoletes RFC 2625 and RFC 3831. |
|
| |
| RFC 4339 | IPv6 Host Configuration of DNS Server Information Approaches |
| |
| Authors: | J. Jeong, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4339 |
|
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise,3GPP, and unmanaged networks) considering multi-solution resolution. |
|
| |
| RFC 4340 | Datagram Congestion Control Protocol (DCCP) |
| |
|
|
The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. |
|
| |
| RFC 4341 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control |
| |
|
|
This document contains the profile for Congestion Control Identifier2 (CCID 2), TCP-like Congestion Control, in the Datagram CongestionControl Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's AdditiveIncrease Multiplicative Decrease (AIMD) congestion control. |
|
| |
| RFC 4342 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) |
| |
|
|
This document contains the profile for Congestion Control Identifier3, TCP-Friendly Rate Control (TFRC), in the Datagram CongestionControl Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit CongestionNotification (ECN), while minimizing abrupt rate changes. |
|
| |
| RFC 4343 | Domain Name System (DNS) Case Insensitivity Clarification |
| |
|
|
Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. |
|
| |
| RFC 4344 | The Secure Shell (SSH) Transport Layer Encryption Modes |
| |
| Authors: | M. Bellare, T. Kohno, C. Namprempre. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4344 |
|
Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.
This document describes new symmetric encryption methods for theSecure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. |
|
| |
| RFC 4345 | Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol |
| |
| Authors: | B. Harris. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4345 |
|
This document specifies methods of using the Arcfour cipher in theSecure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. |
|
| |
| RFC 4346 | The Transport Layer Security (TLS) Protocol Version 1.1 |
| |
|
|
This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 4347 | Datagram Transport Layer Security |
| |
|
|
This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. |
|
| |
| RFC 4348 | Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec |
| |
|
|
This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.
VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB(i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. |
|
| |
| RFC 4349 | High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) |
| |
| Authors: | C. Pignataro, M. Townsley. |
| Date: | February 2006 |
| Formats: | txt html json |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4349 |
|
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelHigh-Level Data Link Control (HDLC) frames over L2TPv3. |
|
| |
| RFC 4350 | A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government |
| |
| Authors: | F. Hendrikx, C. Wallis. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4350 |
|
This document describes a Uniform Resource Name (URN) NamespaceIdentification (NID)convention as prescribed by the World Wide WebConsortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New ZealandGovernment. |
|
| |
| RFC 4351 | Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream |
| |
| Authors: | G. Hellstrom, P. Jones. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4351 |
|
This memo 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 audio and text data within a single RTP session.
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 4352 | RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec |
| |
| Authors: | J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4352 |
|
This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification. |
|
| |
| RFC 4353 | A Framework for Conferencing with the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4353 |
|
The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. |
|
| |
| RFC 4354 | A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service |
| |
| Authors: | M. Garcia-Martin. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4354 |
|
The Open Mobile Alliance (OMA) is defining the Push-to-talk overCellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. |
|
| |
| RFC 4355 | IANA Registration for Enumservices email, fax, mms, ems, and sms |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | January 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4355 |
|
This document registers the Enumservices "email", "fax", "sms","ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. |
|
| |
| RFC 4356 | Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail |
| |
| Authors: | R. Gellens. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4356 |
|
The cellular telephone industry has defined a service known as theMultimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.
One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.
This document specifies how to exchange messages between these two services, including mapping information elements as used in MMSX-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. |
|
| |
| RFC 4357 | Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms |
| |
| Authors: | V. Popov, I. Kurepkin, S. Leontiev. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4357 |
|
This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89,GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use inInternet applications. |
|
| |
| RFC 4358 | A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) |
| |
| Authors: | D. Smith. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4358 |
|
This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the Open MobileAlliance (OMA). OMA defines and manages resources that utilize thisURN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). |
|
| |
| RFC 4359 | The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
| Authors: | B. Weis. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4359 |
|
This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP EncapsulatingSecurity Payload (ESP) as described in RFC 4303 and the revised IPAuthentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. |
|
| |
| RFC 4360 | BGP Extended Communities Attribute |
| |
|
|
This document describes the "extended community" BGP-4 attribute.This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. |
|
| |
| RFC 4361 | Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) |
| |
|
|
This document specifies the format that is to be used for encodingDynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. |
|
| |
| RFC 4362 | RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP |
| |
|
|
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format.This document is a replacement for RFC 3242, which it obsoletes. |
|
| |
| RFC 4363 | Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions |
| |
| Authors: | D. Levi, D. Harrington. |
| Date: | January 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4363 |
|
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 two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MACBridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 andP802.1t-2001 (TM). The other MIB module defines objects for managingVLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v(TM).
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.
This memo supplements RFC 4188 and obsoletes RFC 2674. |
|
| |
| RFC 4364 | BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
|
|
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.
This document obsoletes RFC 2547. |
|
| |
| RFC 4365 | Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4365 |
|
This document provides an Applicability Statement for the VirtualPrivate Network (VPN) solution described in RFC 4364 and other documents listed in the References section. |
|
| |
| RFC 4366 | Transport Layer Security (TLS) Extensions |
| |
|
|
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. |
|
| |
| RFC 4367 | What's in a Name: False Assumptions about DNS Names |
| |
| Authors: | J. Rosenberg, Ed., IAB. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4367 |
|
The Domain Name System (DNS) provides an essential service on theInternet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform ResourceIdentifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. |
|
| |
| RFC 4368 | Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition |
| |
| Authors: | T. Nadeau, S. Hegde. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4368 |
|
This memo defines two MIB modules and corresponding MIB ObjectDefinitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB andMPLS-TE-STD-MIB. |
|
| |
| RFC 4369 | Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) |
| |
| Authors: | K. Gibbons, C. Monia, J. Tseng, F. Travostino. |
| Date: | January 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4369 |
|
The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. |
|
| |
| RFC 4370 | Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control |
| |
| Authors: | R. Weltman. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4370 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. |
|
| |
| RFC 4371 | BCP 101 Update for IPR Trust |
| |
|
|
This document updates BCP 101 to take account of the new IETFIntellectual Property Trust. |
|
| |
| RFC 4372 | Chargeable User Identity |
| |
| Authors: | F. Adrangi, A. Lior, J. Korhonen, J. Loughney. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4372 |
|
This document describes a new Remote Authentication Dial-In UserService (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. |
|
| |
| RFC 4373 | Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) |
| |
| Authors: | R. Harrison, J. Sermersheim, Y. Dong. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4373 |
|
The Lightweight Directory Access Protocol (LDAP) BulkUpdate/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.
The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. |
|
| |
| RFC 4374 | The application/xv+xml Media Type |
| |
| Authors: | G. McCobb. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4374 |
|
This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. |
|
| |
| RFC 4375 | Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain |
| |
| Authors: | K. Carlberg. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4375 |
|
This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. |
|
| |
| RFC 4376 | Requirements for Floor Control Protocols |
| |
| Authors: | P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4376 |
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. |
|
| |
| RFC 4377 | Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks |
| |
| Authors: | T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4377 |
|
This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. |
|
| |
| RFC 4378 | A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) |
| |
| Authors: | D. Allan, Ed., T. Nadeau, Ed.. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4378 |
|
This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-ProtocolLabel Switching (MPLS). The document is structured to outline howOperations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
|
| |
| RFC 4379 | Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures |
| |
|
|
This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching(MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. |
|
| |
| RFC 4380 | Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) |
| |
|
|
We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; theTeredo relays act as IPv6 routers between the Teredo service and the"native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". |
|
| |
| RFC 4381 | Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | M. Behringer. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4381 |
|
This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.
The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode(ATM) or Frame Relay. |
|
| |
| RFC 4382 | MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base |
| |
| Authors: | T. Nadeau, Ed., H. van der Linde, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4382 |
|
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 to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual PrivateNetworks on a Multiprotocol Label Switching (MPLS) Label SwitchingRouter (LSR) supporting this feature. |
|
| |
| RFC 4383 | The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) |
| |
| Authors: | M. Baugher, E. Carrara. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4383 |
|
This memo describes the use of the Timed Efficient Stream Loss- tolerant Authentication (RFC 4082) transform within the Secure Real- time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. |
|
| |
| RFC 4384 | BGP Communities for Data Collection |
| |
|
|
BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. |
|
| |
| RFC 4385 | Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN |
| |
| Authors: | S. Bryant, G. Swallow, L. Martini, D. McPherson. |
| Date: | February 2006 |
| Formats: | txt html json |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4385 |
|
This document describes the preferred design of a PseudowireEmulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated ChannelHeader. The design of these fields is chosen so that an MPLS LabelSwitching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. |
|
| |
| RFC 4386 | Internet X.509 Public Key Infrastructure Repository Locator Service |
| |
| Authors: | S. Boeyen, P. Hallam-Baker. |
| Date: | February 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4386 |
|
This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories. |
|
| |
| RFC 4387 | Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP |
| |
|
|
The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists(CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. |
|
| |
| RFC 4388 | Dynamic Host Configuration Protocol (DHCP) Leasequery |
| |
| Authors: | R. Woundy, K. Kinnear. |
| Date: | February 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6148 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4388 |
|
A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided toDHCPv4 clients. Other processes and devices that already make use ofDHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. |
|
| |
| RFC 4389 | Neighbor Discovery Proxies (ND Proxy) |
| |
| Authors: | D. Thaler, M. Talwar, C. Patel. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4389 |
|
Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. |
|
| |
| RFC 4390 | Dynamic Host Configuration Protocol (DHCP) over InfiniBand |
| |
| Authors: | V. Kashyap. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4390 |
|
IP over Infiniband (IPoIB) link-layer address is 20 octets long.This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol(DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network.This document describes the use of DHCP message fields when implementing DHCP over IPoIB. |
|
| |
| RFC 4391 | Transmission of IP over InfiniBand (IPoIB) |
| |
|
|
This document specifies a method for encapsulating and transmittingIPv4/IPv6 and Address Resolution Protocol (ARP) packets overInfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets.The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. |
|
| |
| RFC 4392 | IP over InfiniBand (IPoIB) Architecture |
| |
| Authors: | V. Kashyap. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4392 |
|
InfiniBand is a high-speed, channel-based interconnect between systems and devices.
This document presents an overview of the InfiniBand architecture.It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. |
|
| |
| RFC 4393 | MIME Type Registrations for 3GPP2 Multimedia Files |
| |
|
|
This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. |
|
| |
| RFC 4394 | A Transport Network View of the Link Management Protocol (LMP) |
| |
| Authors: | D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4394 |
|
The Link Management Protocol (LMP) has been developed as part of theGeneralized MPLS (GMPLS) protocol suite to manage Traffic Engineering(TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths(LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International TelecommunicationUnion (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically SwitchedOptical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. |
|
| |
| RFC 4395 | Guidelines and Registration Procedures for New URI Schemes |
| |
|
|
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. |
|
| |
| RFC 4396 | RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text |
| |
| Authors: | J. Rey, Y. Matsui. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4396 |
|
This document specifies an RTP payload format for the transmission of3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. |
|
| |
| RFC 4397 | A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture |
| |
| Authors: | I. Bryskin, A. Farrel. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4397 |
|
Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths(LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).
This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.
It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. |
|
| |
| RFC 4398 | Storing Certificates in the Domain Name System (DNS) |
| |
|
|
Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).
This document obsoletes RFC 2538. |
|
