| |
| RFC 10 | Documentation conventions |
| |
|
| |
| RFC 16 | M.I.T |
| |
|
| |
| RFC 24 | Documentation Conventions |
| |
|
| |
| RFC 27 | Documentation Conventions |
| |
|
| |
| RFC 33 | New Host-Host Protocol |
| |
|
| |
| RFC 36 | Protocol Notes |
| |
|
| |
| RFC 52 | Updated distribution list |
| |
|
| |
| RFC 54 | Official Protocol Proffering |
| |
| Authors: | S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. |
| Date: | June 1970 |
| Formats: | txt html json |
| Updated by: | RFC 0057 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0054 |
|
|
|
| |
| RFC 66 | NIC - third level ideas and other noise |
| |
|
| |
| RFC 70 | Note on Padding |
| |
|
| |
| RFC 74 | Specifications for Network Use of the UCSB On-Line System |
| |
|
| |
| RFC 80 | Protocols and Data Formats |
| |
|
| |
| RFC 86 | Proposal for a Network Standard Format for a Data Stream to Control Graphics Display |
| |
|
| |
| RFC 98 | Logger Protocol Proposal |
| |
|
| |
| RFC 99 | Network Meeting |
| |
|
| |
| RFC 101 | Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971 |
| |
|
| |
| RFC 102 | Output of the Host-Host Protocol glitch cleaning committee |
| |
|
| |
| RFC 105 | Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB |
| |
|
| |
| RFC 107 | Output of the Host-Host Protocol Glitch Cleaning Committee |
| |
|
| |
| RFC 110 | Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts |
| |
|
| |
| RFC 111 | Pressure from the Chairman |
| |
|
| |
| RFC 113 | Network activity report: UCSB Rand |
| |
| Authors: | E. Harslem, J.F. Heafner, J.E. White. |
| Date: | April 1971 |
| Formats: | txt html json |
| Updated by: | RFC 0227 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0113 |
|
|
|
| |
| RFC 114 | File Transfer Protocol |
| |
|
| |
| RFC 116 | Structure of the May NWG Meeting |
| |
|
| |
| RFC 122 | Network specifications for UCSB's Simple-Minded File System |
| |
|
| |
| RFC 123 | Proffered Official ICP |
| |
|
| |
| RFC 125 | Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream |
| |
|
| |
| RFC 127 | Comments on RFC 123 |
| |
|
| |
| RFC 129 | Request for comments on socket name structure |
| |
| Authors: | E. Harslem, J. Heafner, E. Meyer. |
| Date: | April 1971 |
| Formats: | txt json html |
| Updated by: | RFC 0147 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0129 |
|
|
|
| |
| RFC 137 | Telnet Protocol - a proposed document |
| |
|
| |
| RFC 139 | Discussion of Telnet Protocol |
| |
|
| |
| RFC 140 | Agenda for the May NWG meeting |
| |
|
| |
| RFC 145 | Initial Connection Protocol Control Commands |
| |
|
| |
| RFC 158 | Telnet Protocol: A Proposed Document |
| |
|
| |
| RFC 165 | Proffered Official Initial Connection Protocol |
| |
|
| |
| RFC 171 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0264 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0171 |
|
|
|
| |
| RFC 172 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0265 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0172 |
|
|
|
| |
| RFC 177 | Device independent graphical display description |
| |
|
| |
| RFC 189 | Interim NETRJS specifications |
| |
|
| |
| RFC 193 | NETWORK CHECKOUT |
| |
|
| |
| RFC 204 | Sockets in use |
| |
|
| |
| RFC 212 | NWG meeting on network usage |
| |
| Authors: | Information Sciences Institute University of Southern California. |
| Date: | August 1971 |
| Formats: | txt json html |
| Obsoletes: | RFC 0207 |
| Updated by: | RFC 0222 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0212 |
|
|
|
| |
| RFC 222 | Subject: System programmer's workshop |
| |
|
| |
| RFC 264 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. |
| Date: | January 1972 |
| Formats: | txt json html |
| Obsoletes: | RFC 0171 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0310 |
| Also: | RFC 0265 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0264 |
|
|
|
| |
| RFC 265 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | November 1971 |
| Formats: | txt json html |
| Obsoletes: | RFC 0172 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0281, RFC 0294, RFC 0310 |
| Also: | RFC 0264 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0265 |
|
|
|
| |
| RFC 288 | Network host status |
| |
|
| |
| RFC 318 | Telnet Protocols |
| |
|
| |
| RFC 319 | Network Host Status |
| |
|
| |
| RFC 323 | Formation of Network Measurement Group (NMG) |
| |
|
| |
| RFC 330 | Network Host Status |
| |
|
| |
| RFC 354 | File Transfer Protocol |
| |
|
| |
| RFC 370 | Network Host Status |
| |
|
| |
| RFC 381 | Three aids to improved network operation |
| |
|
| |
| RFC 385 | Comments on the File Transfer Protocol |
| |
|
| |
| RFC 387 | Some experiences in implementing Network Graphics Protocol Level 0 |
| |
|
| |
| RFC 396 | Network Graphics Working Group Meeting - Second Iteration |
| |
|
| |
| RFC 404 | Host Address Changes Involving Rand and ISI |
| |
|
| |
| RFC 442 | Current flow-control scheme for IMPSYS |
| |
|
| |
| RFC 467 | Proposed change to Host-Host Protocol: Resynchronization of connection status |
| |
| Authors: | J.D. Burchfiel, R.S. Tomlinson. |
| Date: | February 1973 |
| Formats: | txt html json |
| Updated by: | RFC 0492 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0467 |
|
|
|
| |
| RFC 482 | Traffic statistics (February 1973) |
| |
|
| |
| RFC 495 | Telnet Protocol specifications |
| |
|
| |
| RFC 538 | Traffic statistics (June 1973) |
| |
|
| |
| RFC 542 | File Transfer Protocol |
| |
|
| |
| RFC 560 | Remote Controlled Transmission and Echoing Telnet option |
| |
|
| |
| RFC 561 | Standardizing Network Mail Headers |
| |
| Authors: | A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. |
| Date: | September 1973 |
| Formats: | txt html json |
| Updated by: | RFC 0680 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0561 |
|
|
|
| |
| RFC 566 | Traffic statistics (August 1973) |
| |
|
| |
| RFC 567 | Cross Country Network Bandwidth |
| |
|
| |
| RFC 579 | Traffic statistics (September 1973) |
| |
|
| |
| RFC 580 | Note to Protocol Designers and Implementers |
| |
|
| |
| RFC 597 | Host status |
| |
|
| |
| RFC 603 | Response to RFC 597: Host status |
| |
|
|
Questions about the ARPANET topology described in RFC 597. |
|
| |
| RFC 607 | Comments on the File Transfer Protocol |
| |
|
|
An old version; see RFC 624; see also RFCs 614, 542 and 640. |
|
| |
| RFC 661 | Protocol information |
| |
|
| |
| RFC 669 | November, 1974, survey of New-Protocol Telnet servers |
| |
|
|
An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679. |
|
| |
| RFC 679 | February, 1975, survey of New-Protocol Telnet servers |
| |
|
| |
| RFC 687 | IMP/Host and Host/IMP Protocol changes |
| |
|
|
Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692. |
|
| |
| RFC 690 | Comments on the proposed Host/IMP Protocol changes |
| |
|
|
Comments on suggestions in RFC 687; see also RFCs 692 and 696. |
|
| |
| RFC 701 | August, 1974, survey of New-Protocol Telnet servers |
| |
|
| |
| RFC 702 | September, 1974, survey of New-Protocol Telnet servers |
| |
|
| |
| RFC 732 | Telnet Data Entry Terminal option |
| |
|
| |
| RFC 760 | DoD standard Internet Protocol |
| |
|
| |
| RFC 791 | Internet Protocol |
| |
|
| |
| RFC 792 | Internet Control Message Protocol |
| |
|
| |
| RFC 793 | Transmission Control Protocol |
| |
|
| |
| RFC 822 | STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES |
| |
|
|
This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. |
|
| |
| RFC 826 | An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware |
| |
|
|
The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. |
|
| |
| RFC 827 | Exterior Gateway Protocol (EGP) |
| |
|
|
This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged. |
|
| |
| RFC 843 | Who talks TCP? - survey of 8 February 83 |
| |
|
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 854 | Telnet Protocol Specification |
| |
|
|
This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639. |
|
| |
| RFC 879 | The TCP Maximum Segment Size and Related Topics |
| |
|
|
This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers". |
|
| |
| RFC 881 | Domain names plan and schedule |
| |
|
|
This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet. |
|
| |
| RFC 882 | Domain names: Concepts and facilities |
| |
|
|
This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities. |
|
| |
| RFC 883 | Domain names: Implementation specification |
| |
|
|
This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software. |
|
| |
| RFC 888 | "STUB" Exterior Gateway Protocol |
| |
|
|
This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document. |
|
| |
| RFC 897 | Domain name system implementation schedule |
| |
|
|
This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA. |
|
| |
| RFC 907 | Host Access Protocol specification |
| |
|
|
This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel. |
|
| |
| RFC 908 | Reliable Data Protocol |
| |
| Authors: | D. Velten, R.M. Hinden, J. Sax. |
| Date: | July 1984 |
| Formats: | txt html json |
| Updated by: | RFC 1151 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0908 |
|
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. |
|
| |
| RFC 950 | Internet Standard Subnetting Procedure |
| |
|
|
This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. |
|
| |
| RFC 951 | Bootstrap Protocol |
| |
|
|
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 952 | DoD Internet host table specification |
| |
|
|
This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date. |
|
| |
| RFC 959 | File Transfer Protocol |
| |
|
|
This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition. |
|
| |
| RFC 976 | UUCP mail interchange format standard |
| |
|
|
This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone. |
|
| |
| RFC 987 | Mapping between X.400 and RFC 822 |
| |
|
|
The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 990 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. |
|
| |
| RFC 1006 | ISO Transport Service on top of the TCP Version: 3 |
| |
|
|
This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible. |
|
| |
| RFC 1011 | Official Internet protocols |
| |
|
|
This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. |
|
| |
| RFC 1026 | Addendum to RFC 987: (Mapping between X.400 and RFC-822) |
| |
|
|
This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements. |
|
| |
| RFC 1034 | Domain names - concepts and facilities |
| |
| Authors: | P. Mockapetris. |
| Date: | November 1987 |
| Formats: | txt html json |
| Obsoletes: | RFC 0973, RFC 0882, RFC 0883 |
| Updated by: | RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 4035, RFC 4592, RFC 5936, RFC 8020, RFC 8482, RFC 8767, RFC 9471 |
| Also: | STD 0013 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 1034 |
|
This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. |
|
| |
| RFC 1035 | Domain names - implementation and specification |
| |
| Authors: | P. Mockapetris. |
| Date: | November 1987 |
| Formats: | txt html json |
| Obsoletes: | RFC 0973, RFC 0882, RFC 0883 |
| Updated by: | RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766, RFC 8482, RFC 8490, RFC 8767, RFC 9619 |
| Also: | STD 0013 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 1035 |
|
This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. |
|
| |
| RFC 1041 | Telnet 3270 regime option |
| |
|
|
This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard. |
|
| |
| RFC 1044 | Internet Protocol on Network System's HYPERchannel: Protocol Specification |
| |
|
|
This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols. |
|
| |
| RFC 1058 | Routing Information Protocol |
| |
|
|
This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community. |
|
| |
| RFC 1060 | Assigned numbers |
| |
|
|
This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited. |
|
| |
| RFC 1071 | Computing the Internet checksum |
| |
| Authors: | R.T. Braden, D.A. Borman, C. Partridge. |
| Date: | September 1988 |
| Formats: | txt json html |
| Updated by: | RFC 1141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1071 |
|
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques. |
|
| |
| RFC 1112 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] |
|
| |
| RFC 1122 | Requirements for Internet Hosts - Communication Layers |
| |
|
|
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] |
|
| |
| RFC 1123 | Requirements for Internet Hosts - Application and Support |
| |
|
|
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] |
|
| |
| RFC 1138 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026. |
|
| |
| RFC 1141 | Incremental updating of the Internet checksum |
| |
|
|
This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique. |
|
| |
| RFC 1149 | Standard for the transmission of IP datagrams on avian carriers |
| |
|
|
This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. |
|
| |
| RFC 1166 | Internet numbers |
| |
|
|
This memo is a status report on the network numbers and autonomous system numbers used in the Internet community. |
|
| |
| RFC 1183 | New DNS RR Definitions |
| |
|
|
This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1195 | Use of OSI IS-IS for routing in TCP/IP and dual environments |
| |
|
|
This RFC specifies an integrated routing protocol, based on the OSIIntra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering TaskForce.
The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of theOSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed inAnnex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available.
Comments should be sent to "isis@merit.edu". |
|
| |
| RFC 1205 | 5250 Telnet interface |
| |
|
|
This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1213 | Management Information Base for Network Management of TCP/IP-based internets: MIB-II |
| |
|
|
This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] |
|
| |
| RFC 1229 | Extensions to the generic-interface MIB |
| |
|
|
This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK] |
|
| |
| RFC 1230 | IEEE 802.4 Token Bus MIB |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK] |
|
| |
| RFC 1231 | IEEE 802.5 Token Ring MIB |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] |
|
| |
| RFC 1232 | Definitions of managed objects for the DS1 Interface type |
| |
|
| |
| RFC 1233 | Definitions of managed objects for the DS3 Interface type |
| |
|
|
This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1242 | Benchmarking Terminology for Network Interconnection Devices |
| |
|
|
This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. The terms defined in this memo will be used in additional memos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 1247 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1248 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines an experimental 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 OSPF Version 2. [STANDARDS-TRACK] |
|
| |
| RFC 1271 | Remote Network Monitoring Management Information Base |
| |
|
|
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 remote network monitoring devices. [STANDARDS-TRACK] |
|
| |
| RFC 1285 | FDDI Management Information Base |
| |
|
|
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 devices which implement the FDDI. [STANDARDS-TRACK] |
|
| |
| RFC 1321 | The MD5 Message-Digest Algorithm |
| |
|
|
This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1327 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988)Recommendations on Message Handling Systems / ISO IEC 10021 MessageOriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings.The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148[Kille86a,Kille87a] which it obsoletes.
This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on theDARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. |
|
| |
| RFC 1329 | Thoughts on Address Resolution for Dual MAC FDDI Networks |
| |
|
|
In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1332 | The PPP Internet Protocol Control Protocol (IPCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring theInternet Protocol [2] over PPP, and a method to negotiate and use VanJacobson TCP/IP header compression [3] with PPP.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 1350 | The TFTP Protocol (Revision 2) |
| |
|
|
TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK] |
|
| |
| RFC 1379 | Extending TCP for Transactions -- Concepts |
| |
|
|
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1408 | Telnet Environment Option |
| |
|
|
This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. |
|
| |
| RFC 1459 | Internet Relay Chat Protocol |
| |
|
|
The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.
The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. |
|
| |
| RFC 1521 | MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies |
| |
|
|
STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC822.
In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.
This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data. Such extensions are the subject of a companion document [RFC-1522].
This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H. |
|
| |
| RFC 1536 | Common DNS Implementation Errors and Suggested Fixes |
| |
| Authors: | A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. |
| Date: | October 1993 |
| Formats: | txt html json |
| Updated by: | RFC 9210 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1536 |
|
This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND(versions 4.8.3 and 4.9 which the authors referred to) to serve as an example. |
|
| |
| RFC 1548 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1570 | PPP LCP Extensions |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1602 | The Internet Standards Process -- Revision 2 |
| |
| Authors: | Internet Architecture Board, Internet Engineering Steering Group. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1602 |
|
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C. |
|
| |
| RFC 1603 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. |
|
| |
| RFC 1661 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. |
|
| |
| RFC 1706 | DNS NSAP Resource Records |
| |
|
|
OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet. Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System(DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.
This document obsoletes RFC 1348 and RFC 1637. |
|
| |
| RFC 1715 | The H Ratio for Address Assignment Efficiency |
| |
|
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list. |
|
| |
| RFC 1738 | Uniform Resource Locators (URL) |
| |
|
|
This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. |
|
| |
| RFC 1748 | IEEE 802.5 MIB using SMIv2 |
| |
|
|
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 subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] |
|
| |
| RFC 1778 | The String Representation of Standard Attribute Syntaxes |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. |
|
| |
| RFC 1793 | Extending OSPF to Support Demand Circuits |
| |
|
|
This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.
Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.
While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.
The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface).
This memo provides functionality similar to that specified for RIP in[2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, becauseOSPF employs link-state routing technology as opposed to RIP'sDistance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 1808 | Relative Uniform Resource Locators |
| |
|
|
A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators. |
|
| |
| RFC 1812 | Requirements for IP Version 4 Routers |
| |
|
|
This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] |
|
| |
| RFC 1833 | Binding Protocols for ONC RPC Version 2 |
| |
|
|
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] |
|
| |
| RFC 1846 | SMTP 521 Reply Code |
| |
|
|
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. |
|
| |
| RFC 1858 | Security Considerations for IP Fragment Filtering |
| |
| Authors: | G. Ziemba, D. Reed, P. Traina. |
| Date: | October 1995 |
| Formats: | txt html json |
| Updated by: | RFC 3128 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1858 |
|
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. |
|
| |
| RFC 1886 | DNS Extensions to support IP version 6 |
| |
|
|
This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. |
|
| |
| RFC 1888 | OSI NSAPs and IPv6 |
| |
| Authors: | J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. |
| Date: | August 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4048 |
| Updated by: | RFC 4548 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1888 |
|
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. |
|
| |
| RFC 1894 | An Extensible Message Format for Delivery Status Notifications |
| |
|
|
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.
Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.
NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change. |
|
| |
| RFC 1918 | Address Allocation for Private Internets |
| |
|
|
This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1930 | Guidelines for creation, selection, and registration of an Autonomous System (AS) |
| |
|
|
This memo discusses when it is appropriate to register and utilize anAutonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior GatewayProtocol, now at historical status; see [EGP]), BGP (Border GatewayProtocol, the current de facto standard for inter-AS routing; see[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which theInternet is expected to adopt when BGP becomes obsolete; see [IDRP]).It should be noted that the IDRP equivalent of an AS is the RDI, orRouting Domain Identifier. |
|
| |
| RFC 1939 | Post Office Protocol - Version 3 |
| |
|
|
The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK] |
|
| |
| RFC 1958 | Architectural Principles of the Internet |
| |
|
|
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. |
|
| |
| RFC 1962 | The PPP Compression Control Protocol (CCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.
This document defines a method for negotiating data compression overPPP links. |
|
| |
| RFC 1964 | The Kerberos Version 5 GSS-API Mechanism |
| |
|
|
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK] |
|
| |
| RFC 1966 | BGP Route Reflection An alternative to full mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 1987 | Ipsilon's General Switch Management Protocol Specification Version 1.1 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | August 1996 |
| Formats: | txt html json |
| Updated by: | RFC 2297 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1987 |
|
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. |
|
| |
| RFC 1994 | PPP Challenge Handshake Authentication Protocol (CHAP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. |
|
| |
| RFC 1995 | Incremental Zone Transfer in DNS |
| |
|
|
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. |
|
| |
| RFC 1997 | BGP Communities Attribute |
| |
|
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets.
This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers.
The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet. |
|
| |
| RFC 2002 | IP Mobility Support |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 2003 | IP Encapsulation within IP |
| |
|
|
This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IPDestination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP. |
|
| |
| RFC 2015 | MIME Security with Pretty Good Privacy (PGP) |
| |
|
|
This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC1847. |
|
| |
| RFC 2026 | The Internet Standards Process -- Revision 3 |
| |
| Authors: | S. Bradner. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1602, RFC 1871 |
| Updated by: | RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282 |
| Also: | BCP 0009 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2026 |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
|
| |
| RFC 2028 | The Organizations Involved in the IETF Standards Process |
| |
|
|
This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF WorkingGroups and the relationship between the IETF and the InternetSociety. |
|
| |
| RFC 2045 | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions. |
|
| |
| RFC 2046 | Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types |
| |
|
|
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document,RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2047 | MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data inInternet mail header fields.
Other documents in this series include:
+ RFC 2045, which specifies the various headers used to describe the structure of MIME messages.
+ RFC 2046, which defines the general structure of the MIME media typing system and defines an initial set of media types,
+ RFC 2048, which specifies various IANA registration procedures for MIME-related facilities, and
+ RFC 2049, which describes MIME conformance criteria and provides some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions. |
|
| |
| RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities:
(1) media types,
(2) external body access types,
(3) content-transfer-encodings.
Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2072 | Router Renumbering Guide |
| |
|
|
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes inInternet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.
Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.
Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. |
|
| |
| RFC 2077 | The Model Primary Content Type for Multipurpose Internet Mail Extensions |
| |
| Authors: | S. Nelson, C. Parks, Mitra. |
| Date: | January 1997 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2077 |
|
The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK] |
|
| |
| RFC 2088 | IMAP4 non-synchronizing literals |
| |
|
|
The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK] |
|
| |
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication |
| |
| Authors: | H. Krawczyk, M. Bellare, R. Canetti. |
| Date: | February 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6151 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2104 |
|
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function. |
|
| |
| RFC 2113 | IP Router Alert Option |
| |
|
|
This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path. |
|
| |
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| |
|
|
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: |
|
| |
| RFC 2130 | The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 |
| |
| Authors: | C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. |
| Date: | April 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6055 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2130 |
|
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. |
|
| |
| RFC 2131 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 2132 | DHCP Options and BOOTP Vendor Extensions |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called"options."
This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments [22].
All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions. |
|
| |
| RFC 2136 | Dynamic Updates in the Domain Name System (DNS UPDATE) |
| |
|
|
The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met. |
|
| |
| RFC 2153 | PPP Vendor Extensions |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines a general mechanism for proprietary vendor extensions. |
|
| |
| RFC 2163 | Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) |
| |
|
|
This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed.
This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.
RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group. |
|
| |
| RFC 2165 | Service Location Protocol |
| |
|
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. |
|
| |
| RFC 2168 | Resolution of Uniform Resource Identifiers using the Domain Name System |
| |
|
|
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2176 | IPv4 over MAPOS Version 1 |
| |
|
|
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP). |
|
| |
| RFC 2181 | Clarifications to the DNS Specification |
| |
|
|
This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK] |
|
| |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |
| |
|
|
This memo provides a mechanism whereby messages conforming to theMIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC2049] can convey presentational information. It specifies the"Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and[RFC 822]. The information presented herein supplements but does not replace that found in those documents.
This document is a revision to the Experimental protocol defined inRFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the FileTransfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values. |
|
| |
| RFC 2198 | RTP Payload for Redundant Audio Data |
| |
| Authors: | C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. |
| Date: | September 1997 |
| Formats: | txt json html |
| Updated by: | RFC 6354 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2198 |
|
This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. |
|
| |
| RFC 2203 | RPCSEC_GSS Protocol Specification |
| |
| Authors: | M. Eisler, A. Chiu, L. Ling. |
| Date: | September 1997 |
| Formats: | txt html json |
| Updated by: | RFC 5403 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2203 |
|
This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services ApplicationProgramming Interface (referred to henceforth as GSS-API). |
|
| |
| RFC 2205 | Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification |
| |
| Authors: | R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. |
| Date: | September 1997 |
| Formats: | txt json html |
| Updated by: | RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2205 |
|
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. |
|
| |
| RFC 2222 | Simple Authentication and Security Layer (SASL) |
| |
|
|
This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK] |
|
| |
| RFC 2223 | Instructions to RFC Authors |
| |
|
|
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2225 | Classical IP and ARP over ATM |
| |
|
|
This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK] |
|
| |
| RFC 2236 | Internet Group Management Protocol, Version 2 |
| |
|
|
This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112.
IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.
This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). |
|
| |
| RFC 2244 | ACAP -- Application Configuration Access Protocol |
| |
| Authors: | C. Newman, J. G. Myers. |
| Date: | November 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6075 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2244 |
|
The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted. |
|
| |
| RFC 2246 | The TLS Protocol Version 1.0 |
| |
|
|
This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy 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 2247 | Using Domains in LDAP/X.500 Distinguished Names |
| |
| Authors: | S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. |
| Date: | January 1998 |
| Formats: | txt json html |
| Updated by: | RFC 4519, RFC 4524 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2247 |
|
This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK] |
|
| |
| RFC 2251 | Lightweight Directory Access Protocol (v3) |
| |
|
|
The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK] |
|
| |
| RFC 2252 | Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions |
| |
|
|
This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2253 | Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names |
| |
|
|
The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight DirectoryAccess Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. |
|
| |
| RFC 2254 | The String Representation of LDAP Search Filters |
| |
|
|
This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 2255 | The LDAP URL Format |
| |
|
|
This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK] |
|
| |
| RFC 2256 | A Summary of the X.500(96) User Schema for use with LDAPv3 |
| |
|
|
This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK] |
|
| |
| RFC 2276 | Architectural Principles of Uniform Resource Name Resolution |
| |
|
|
This document addresses the issues of the discovery of URN (UniformResource Name) resolver services that in turn will directly translateURNs into URLs (Uniform Resource Locators) and URCs (Uniform ResourceCharacteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately. |
|
| |
| RFC 2284 | PPP Extensible Authentication Protocol (EAP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines the PPP Extensible Authentication Protocol. |
|
| |
| RFC 2290 | Mobile-IPv4 Configuration Option for PPP IPCP |
| |
|
|
Mobile IP [RFC 2002] defines media-independent procedures by which aMobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to theInternet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP[RFC 1332], and PPP [RFC 1661] is assumed. |
|
| |
| RFC 2308 | Negative Caching of DNS Queries (DNS NCACHE) |
| |
|
|
[RFC1034] provided a description of how to cache negative responses.It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section4.3.4].
Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name.
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver. |
|
| |
| RFC 2309 | Recommendations on Queue Management and Congestion Avoidance in the Internet |
| |
| Authors: | B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7567 |
| Updated by: | RFC 7141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2309 |
|
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. |
|
| |
| RFC 2324 | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) |
| |
|
|
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. |
|
| |
| RFC 2327 | SDP: Session Description Protocol |
| |
|
|
This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. |
|
| |
| RFC 2328 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
The differences between this memo and RFC 2178 are explained inAppendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2330 | Framework for IP Performance Metrics |
| |
|
|
The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2342 | IMAP4 Namespace |
| |
|
|
This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS- TRACK] |
|
| |
| RFC 2355 | TN3270 Enhancements |
| |
|
|
This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.
This protocol is negotiated under the TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime Option as defined in RFC 1041[1]. |
|
| |
| RFC 2370 | The OSPF Opaque LSA Option |
| |
|
|
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK] |
|
| |
| RFC 2377 | Naming Plan for Internet Directory-Enabled Applications |
| |
| Authors: | A. Grimstad, R. Huber, S. Sataluri, M. Wahl. |
| Date: | September 1998 |
| Formats: | txt html json |
| Updated by: | RFC 4519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2377 |
|
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach. |
|
| |
| RFC 2385 | Protection of BGP Sessions via the TCP MD5 Signature Option |
| |
|
|
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. |
|
| |
| RFC 2396 | Uniform Resource Identifiers (URI): Generic Syntax |
| |
|
|
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.
This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. |
|
| |
| RFC 2401 | Security Architecture for the Internet Protocol |
| |
|
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
|
|
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] |
|
| |
| RFC 2418 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF AreaDirectors. |
|
| |
| RFC 2434 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. |
|
| |
| RFC 2449 | POP3 Extension Mechanism |
| |
|
|
This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK] |
|
| |
| RFC 2453 | RIP Version 2 |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.
A companion document will define the SNMP MIB objects for RIP-2 [2].An additional document will define cryptographic security improvements for RIP-2 [3]. |
|
| |
| RFC 2460 | Internet Protocol, Version 6 (IPv6) Specification |
| |
|
|
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. |
|
| |
| RFC 2461 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
|
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 2464 | Transmission of IPv6 Packets over Ethernet Networks |
| |
|
|
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] |
|
| |
| RFC 2467 | Transmission of IPv6 Packets over FDDI Networks |
| |
|
|
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS- TRACK] |
|
| |
| RFC 2470 | Transmission of IPv6 Packets over Token Ring Networks |
| |
| Authors: | M. Crawford, T. Narten, S. Thomas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2470 |
|
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK] |
|
| |
| RFC 2474 | Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers |
| |
|
|
Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:
- setting bits in an IP header field at network boundaries(autonomous system boundaries, internal administrative boundaries, or hosts),- using those bits to determine how packets are forwarded by the nodes inside the network, and- conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.
The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.
For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH]. |
|
| |
| RFC 2475 | An Architecture for Differentiated Services |
| |
| Authors: | S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. |
| Date: | December 1998 |
| Formats: | txt html json |
| Updated by: | RFC 3260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2475 |
|
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field[DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks. |
|
| |
| RFC 2491 | IPv6 over Non-Broadcast Multiple Access (NBMA) networks |
| |
| Authors: | G. Armitage, P. Schulter, M. Jork, G. Harter. |
| Date: | January 1999 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2491 |
|
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.
Dynamic NBMA shortcuts are achieved through the use of IPv6 NeighborDiscovery protocol operation within Logical Links, and inter-routerNHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported. |
|
| |
| RFC 2492 | IPv6 over ATM Networks |
| |
| Authors: | G. Armitage, P. Schulter, M. Jork. |
| Date: | January 1999 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2492 |
|
This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths(when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. |
|
| |
| RFC 2497 | Transmission of IPv6 Packets over ARCnet Networks |
| |
|
|
This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK] |
|
| |
| RFC 2533 | A Syntax for Describing Media Feature Sets |
| |
|
|
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1].A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3].
This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.
An algorithm for feature set matching is also described here. |
|
| |
| RFC 2535 | Domain Name System Security Extensions |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2065 |
| Obsoleted by: | RFC 4033, RFC 4034, RFC 4035 |
| Updates: | RFC 2181, RFC 1035, RFC 1034 |
| Updated by: | RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2535 |
|
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.
The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.
This document incorporates feedback on RFC 2065 from early implementers and potential users. |
|
| |
| RFC 2536 | DSA KEYs and SIGs in the Domain Name System (DNS) |
| |
|
|
A standard method for storing US Government Digital SignatureAlgorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. |
|
| |
| RFC 2539 | Storage of Diffie-Hellman Keys in the Domain Name System (DNS) |
| |
|
|
A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records. |
|
| |
| RFC 2544 | Benchmarking Methodology for Network Interconnect Devices |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 2553 | Basic Socket Interface Extensions for IPv6 |
| |
|
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. |
|
| |
| RFC 2555 | 30 Years of RFCs |
| |
|
|
The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community. |
|
| |
| RFC 2560 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
| Authors: | M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6960 |
| Updated by: | RFC 6277 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2560 |
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK] |
|
| |
| RFC 2563 | DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients |
| |
|
|
Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum.To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-localIP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. |
|
| |
| RFC 2581 | TCP Congestion Control |
| |
|
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. |
|
| |
| RFC 2590 | Transmission of IPv6 Packets over Frame Relay Networks Specification |
| |
| Authors: | A. Conta, A. Malis, M. Mueller. |
| Date: | May 1999 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2590 |
|
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. |
|
| |
| RFC 2595 | Using TLS with IMAP, POP3 and ACAP |
| |
|
|
Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK] |
|
| |
| RFC 2597 | Assured Forwarding PHB Group |
| |
| Authors: | J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. |
| Date: | June 1999 |
| Formats: | txt html json |
| Updated by: | RFC 3260 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2597 |
|
This document defines a general use Differentiated Services (DS)[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class. |
|
| |
| RFC 2606 | Reserved Top Level DNS Names |
| |
|
|
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. |
|
| |
| RFC 2608 | Service Location Protocol, Version 2 |
| |
|
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. |
|
| |
| RFC 2616 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. |
| Date: | June 1999 |
| Formats: | txt ps html pdf json |
| Obsoletes: | RFC 2068 |
| Obsoleted by: | RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 |
| Updated by: | RFC 2817, RFC 5785, RFC 6266, RFC 6585 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2616 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. |
|
| |
| RFC 2622 | Routing Policy Specification Language (RPSL) |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. |
| Date: | June 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2280 |
| Updated by: | RFC 4012, RFC 7909 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2622 |
|
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. |
|
| |
| RFC 2634 | Enhanced Security Services for S/MIME |
| |
|
|
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] |
|
| |
| RFC 2648 | A URN Namespace for IETF Documents |
| |
|
|
A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace. |
|
| |
| RFC 2661 | Layer Two Tunneling Protocol "L2TP" |
| |
| Authors: | W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. |
| Date: | August 1999 |
| Formats: | txt html json |
| Updated by: | RFC 9601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2661 |
|
This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications. |
|
| |
| RFC 2672 | Non-Terminal DNS Name Redirection |
| |
|
|
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK] |
|
| |
| RFC 2673 | Binary Labels in the Domain Name System |
| |
|
|
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK] |
|
| |
| RFC 2683 | IMAP4 Implementation Recommendations |
| |
|
|
The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community. |
|
| |
| RFC 2705 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. |
| Date: | October 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2705 |
|
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
|
| |
| RFC 2710 | Multicast Listener Discovery (MLD) for IPv6 |
| |
|
|
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as MulticastListener Discovery or MLD. MLD is derived from version 2 of IPv4'sInternet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. |
|
| |
| RFC 2711 | IPv6 Router Alert Option |
| |
| Authors: | C. Partridge, A. Jackson. |
| Date: | October 1999 |
| Formats: | txt html json |
| Updated by: | RFC 6398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2711 |
|
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. |
|
| |
| RFC 2725 | Routing Policy System Security |
| |
| Authors: | C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. |
| Date: | December 1999 |
| Formats: | txt html json |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2725 |
|
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. |
|
| |
| RFC 2736 | Guidelines for Writers of RTP Payload Format Specifications |
| |
|
|
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. |
|
| |
| RFC 2739 | Calendar Attributes for vCard and LDAP |
| |
| Authors: | T. Small, D. Hennessy, F. Dawson. |
| Date: | January 2000 |
| Formats: | txt html json |
| Updated by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2739 |
|
When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event.
In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time.
This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include:
- Manual transfer of the information;
- Personal data exchange using the vCard format; and
- Directory lookup using the LDAP protocol. |
|
| |
| RFC 2743 | Generic Security Service Application Program Interface Version 2, Update 1 |
| |
|
|
The Generic Security Service Application Program Interface (GSS-API),Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. |
|
| |
| RFC 2744 | Generic Security Service API Version 2 : C-bindings |
| |
|
|
This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC-2743 [GSSAPI]. It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track.
The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
|
| |
| RFC 2747 | RSVP Cryptographic Authentication |
| |
| Authors: | F. Baker, B. Lindell, M. Talwar. |
| Date: | January 2000 |
| Formats: | txt html json |
| Updated by: | RFC 3097 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2747 |
|
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. |
|
| |
| RFC 2748 | The COPS (Common Open Policy Service) Protocol |
| |
| Authors: | D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. |
| Date: | January 2000 |
| Formats: | txt json html |
| Updated by: | RFC 4261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2748 |
|
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies. |
|
| |
| RFC 2766 | Network Address Translation - Protocol Translation (NAT-PT) |
| |
|
|
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT]. |
|
| |
| RFC 2772 | 6Bone Backbone Routing Guidelines |
| |
|
|
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. |
|
| |
| RFC 2780 | IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers |
| |
|
|
This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. |
|
| |
| RFC 2782 | A DNS RR for specifying the location of services (DNS SRV) |
| |
|
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. |
|
| |
| RFC 2784 | Generic Routing Encapsulation (GRE) |
| |
|
|
This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. |
|
| |
| RFC 2798 | Definition of the inetOrgPerson LDAP Object Class |
| |
|
|
While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. |
|
| |
| RFC 2817 | Upgrading to TLS Within HTTP/1.1 |
| |
|
|
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP +TLS server can disambiguate traffic intended for several hostnames at a single IP address.
Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes newIANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.
This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace(http://example.org/ and https://example.org/ are not equivalent). |
|
| |
| RFC 2818 | HTTP Over TLS |
| |
|
|
This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP[RFC2817]. |
|
| |
| RFC 2821 | Simple Mail Transfer Protocol |
| |
|
|
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30],
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2], and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15].
Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship. |
|
| |
| RFC 2822 | Internet Message Format |
| |
|
|
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| RFC 2827 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
|
|
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
|
| |
| RFC 2829 | Authentication Methods for LDAP |
| |
|
|
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. |
|
| |
| RFC 2830 | Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
| |
|
|
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request. |
|
| |
| RFC 2832 | NSI Registry Registrar Protocol (RRP) Version 1.1.0 |
| |
| Authors: | S. Hollenbeck, M. Srivastava. |
| Date: | May 2000 |
| Formats: | txt json html |
| Updated by: | RFC 3632 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2832 |
|
This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry.
Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services.
This document is being discussed on the "rrp" mailing list. To join the list, send a message to <majordomo@NSIRegistry.com&rt; with the words "subscribe rrp" in the body of the message. There is also a web site for the mailing list archives at<http://www.NSIRegistry.net/maillist/rrp&rt;. |
|
| |
| RFC 2834 | ARP and IP Broadcast over HIPPI-800 |
| |
|
|
This document specifies a method for resolving IP addresses to ANSIHigh-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte SystemNetwork, GSN). This document (when combined with RFC-2067 "IP overHIPPI") obsoletes RFC-1374. |
|
| |
| RFC 2835 | IP and ARP over HIPPI-6400 (GSN) |
| |
|
|
The ANSI T11.1 task force has standardized HIPPI-6400 also known asGigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified inHIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].
HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs[10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. |
|
| |
| RFC 2845 | Secret Key Transaction Authentication for DNS (TSIG) |
| |
|
|
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. |
|
| |
| RFC 2846 | GSTN Address Element Extensions in E-mail Services |
| |
|
|
There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in[1]. |
|
| |
| RFC 2850 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC1601. |
|
| |
| RFC 2863 | The Interfaces Group MIB |
| |
|
|
This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS TRACK] |
|
| |
| RFC 2865 | Remote Authentication Dial In User Service (RADIUS) |
| |
|
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2866 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2868 | RADIUS Attributes for Tunnel Protocol Support |
| |
| Authors: | G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. |
| Date: | June 2000 |
| Formats: | txt json html |
| Updates: | RFC 2865 |
| Updated by: | RFC 3575 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2868 |
|
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. |
|
| |
| RFC 2869 | RADIUS Extensions |
| |
|
|
This document describes additional attributes for carrying authentication, authorization and accounting information between aNetwork Access Server (NAS) and a shared Accounting Server using theRemote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. |
|
| |
| RFC 2874 | DNS Extensions to Support IPv6 Address Aggregation and Renumbering |
| |
|
|
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. |
|
| |
| RFC 2895 | Remote Network Monitoring MIB Protocol Identifier Reference |
| |
|
|
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network MonitoringManagement Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON ProtocolIdentifier Macros document [RFC2896] now contains the non-normative portion of that specification.
This document obsoletes RFC 2074. |
|
| |
| RFC 2910 | Internet Printing Protocol/1.1: Encoding and Transport |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. |
| Date: | September 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2565 |
| Obsoleted by: | RFC 8010 |
| Updated by: | RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2910 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext TransferProtocol (HTTP) a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics [RFC2911]Internet Printing Protocol/1.1: Encoding and Transport (this document)Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.1. A few OPTIONAL operator operations have been added to IPP/1.1.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2911 | Internet Printing Protocol/1.1: Model and Semantics |
| |
|
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics (this document)Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called"application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2914 | Congestion Control Principles |
| |
|
|
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols. |
|
| |
| RFC 2918 | Route Refresh Capability for BGP-4 |
| |
|
|
This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes. |
|
| |
| RFC 2930 | Secret Key Establishment for DNS (TKEY RR) |
| |
|
|
[RFC 2845] provides a means of authenticating Domain Name System(DNS) queries and responses using shared secret keys via theTransaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. |
|
| |
| RFC 2954 | Definitions of Managed Objects for Frame Relay Service |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TransmissionControl Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service.
This document obsoletes RFC 1604. |
|
| |
| RFC 2955 | Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function |
| |
| Authors: | K. Rehbehn, O. Nicklass, G. Mouradian. |
| Date: | October 2000 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2955 |
|
This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) forPermanent Virtual Connections (PVC) between Frame Relay andAsynchronous Transfer Mode (ATM) technologies. |
|
| |
| RFC 2960 | Stream Control Transmission Protocol |
| |
| Authors: | R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. |
| Date: | October 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4960 |
| Updated by: | RFC 3309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2960 |
|
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 2961 | RSVP Refresh Overhead Reduction Extensions |
| |
| Authors: | L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini. |
| Date: | April 2001 |
| Formats: | txt html json |
| Updated by: | RFC 5063 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2961 |
|
This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP(Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages.The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues. |
|
| |
| RFC 2980 | Common NNTP Extensions |
| |
|
|
In this document, a number of popular extensions to the Network NewsTransfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions. |
|
| |
| RFC 2986 | PKCS #10: Certification Request Syntax Specification Version 1.7 |
| |
|
|
This memo represents a republication of PKCS #10 v1.7 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.
This memo describes a syntax for certification requests. |
|
| |
| RFC 3005 | IETF Discussion List Charter |
| |
|
|
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed.Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. |
|
| |
| RFC 3008 | Domain Name System Security (DNSSEC) Signing Authority |
| |
|
|
This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. |
|
| |
| RFC 3020 | Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function |
| |
| Authors: | P. Pate, B. Lynch, K. Rehbehn. |
| Date: | December 2000 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3020 |
|
This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information. |
|
| |
| RFC 3023 | XML Media Types |
| |
|
|
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be". |
|
| |
| RFC 3031 | Multiprotocol Label Switching Architecture |
| |
|
|
This document specifies the architecture for Multiprotocol LabelSwitching (MPLS). |
|
| |
| RFC 3032 | MPLS Label Stack Encoding |
| |
| Authors: | E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. |
| Date: | January 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3032 |
|
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. |
|
| |
| RFC 3038 | VCID Notification over ATM link for LDP |
| |
| Authors: | K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. |
| Date: | January 2001 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3038 |
|
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. |
|
| |
| RFC 3046 | DHCP Relay Agent Information Option |
| |
|
|
Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use theDynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.However, a number of security and scaling problems arise with such"public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132.
The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originatedDHCP packets to a DHCP server. Servers recognizing the Relay AgentInformation option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.
The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem. |
|
| |
| RFC 3057 | ISDN Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | February 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3057 |
|
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. |
|
| |
| RFC 3060 | Policy Core Information Model -- Version 1 Specification |
| |
| Authors: | B. Moore, E. Ellesson, J. Strassner, A. Westerinen. |
| Date: | February 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3060 |
|
This document presents the object-oriented information model for representing policy information developed jointly in the IETF PolicyFramework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. |
|
| |
| RFC 3083 | Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
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 basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the BaselinePrivacy Interface (BPI), which provides data privacy for DOCSIS 1.0(Data-Over-Cable Service Interface Specifications) compliant CableModems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.
This memo specifies a MIB module in a manner that is compliant to theSMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards.
CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. |
|
| |
| RFC 3090 | DNS Security Extension Clarification on Zone Status |
| |
|
|
The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. |
|
| |
| RFC 3095 | RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed |
| |
| Authors: | C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. |
| Date: | July 2001 |
| Formats: | txt html json |
| Updated by: | RFC 3759, RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3095 |
|
This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol), UDP/IP, and ESP/IP(Encapsulating Security Payload) headers.
Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common.
This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards trackMobile IPv6 has been completed. |
|
| |
| RFC 3106 | ECML v1.1: Field Specifications for E-Commerce |
| |
|
|
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. |
|
| |
| RFC 3107 | Carrying Label Information in BGP-4 |
| |
|
|
This document specifies the way in which the label mapping information for a particular route is piggybacked in the same BorderGateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching(MPLS) label which is mapped to that route. |
|
| |
| RFC 3110 | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) |
| |
|
|
This document describes how to produce RSA/SHA1 SIG resource records(RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2.
Since the adoption of a Proposed Standard for RSA signatures in theDNS (Domain Name Space), advances in hashing have been made. A newDNS signature algorithm is defined to make these advances available in SIG RRs. The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made toDNS security. |
|
| |
| RFC 3146 | Transmission of IPv6 Packets over IEEE 1394 Networks |
| |
| Authors: | K. Fujisawa, A. Onoe. |
| Date: | October 2001 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3146 |
|
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. |
|
| |
| RFC 3161 | Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) |
| |
| Authors: | C. Adams, P. Cain, D. Pinkas, R. Zuccherato. |
| Date: | August 2001 |
| Formats: | txt json html |
| Updated by: | RFC 5816 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3161 |
|
This document describes the format of a request sent to a TimeStamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. |
|
| |
| RFC 3162 | RADIUS and IPv6 |
| |
| Authors: | B. Aboba, G. Zorn, D. Mitton. |
| Date: | August 2001 |
| Formats: | txt html json |
| Updated by: | RFC 8044 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3162 |
|
This document specifies the operation of RADIUS (RemoteAuthentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. |
|
| |
| RFC 3168 | The Addition of Explicit Congestion Notification (ECN) to IP |
| |
|
|
This memo specifies the incorporation of ECN (Explicit CongestionNotification) to TCP and IP, including ECN's use of two bits in theIP header. |
|
| |
| RFC 3172 | Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") |
| |
|
|
This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. The "arpa" domain is used to support a class of infrastructural identifier spaces, providing a distributed database that translates elements of a structured name space derived from a protocol family to service names. The efficient and reliable operation of this DNS space is essential to the integrity of operation of various services within the Internet. The Internet Architecture Board (IAB) has the responsibility, in cooperation with the Internet Corporation forAssigned Names and Numbers (ICANN), to manage the "arpa" domain.This document describes the principles used by the IAB in undertaking this role. |
|
| |
| RFC 3174 | US Secure Hash Algorithm 1 (SHA1) |
| |
|
|
The purpose of this document is to make the SHA-1 (Secure HashAlgorithm 1) hash algorithm conveniently available to the Internet community. The United States of America has adopted the SHA-1 hash algorithm described herein as a Federal Information ProcessingStandard. Most of the text herein was taken by the authors from FIPS180-1. Only the C code implementation is "original". |
|
| |
| RFC 3175 | Aggregation of RSVP for IPv4 and IPv6 Reservations |
| |
| Authors: | F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. |
| Date: | September 2001 |
| Formats: | txt json html |
| Updated by: | RFC 5350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3175 |
|
This document describes the use of a single RSVP (ResourceReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM(Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. |
|
| |
| RFC 3201 | Definitions of Managed Objects for Circuit to Interface Translation |
| |
| Authors: | R. Steinberger, O. Nicklass. |
| Date: | January 2002 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3201 |
|
This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existingMIB modules. |
|
| |
| RFC 3202 | Definitions of Managed Objects for Frame Relay Service Level Definitions |
| |
| Authors: | R. Steinberger, O. Nicklass. |
| Date: | January 2002 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3202 |
|
This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service Level Definitions. |
|
| |
| RFC 3203 | DHCP reconfigure extension |
| |
| Authors: | Y. T'Joens, C. Hublet, P. De Schrijver. |
| Date: | December 2001 |
| Formats: | txt html json |
| Updated by: | RFC 6704 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3203 |
|
This document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. |
|
| |
| RFC 3204 | MIME media types for ISUP and QSIG Objects |
| |
| Authors: | E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. |
| Date: | December 2001 |
| Formats: | txt json html |
| Updated by: | RFC 3459, RFC 5621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3204 |
|
This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identifyISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. |
|
| |
| RFC 3207 | SMTP Service Extension for Secure SMTP over Transport Layer Security |
| |
|
|
This document describes an extension to the SMTP (Simple MailTransfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. |
|
| |
| RFC 3209 | RSVP-TE: Extensions to RSVP for LSP Tunnels |
| |
| Authors: | D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. |
| Date: | December 2001 |
| Formats: | txt json html |
| Updated by: | RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3209 |
|
This document describes the use of RSVP (Resource ReservationProtocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.
We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. |
|
| |
| RFC 3212 | Constraint-Based LSP Setup using LDP |
| |
| Authors: | B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. |
| Date: | January 2002 |
| Formats: | txt html json |
| Updated by: | RFC 3468, RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3212 |
|
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol).
This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP. |
|
| |
| RFC 3219 | Telephony Routing over IP (TRIP) |
| |
| Authors: | J. Rosenberg, H. Salama, M. Squire. |
| Date: | January 2002 |
| Formats: | txt json html |
| Updated by: | RFC 8602 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3219 |
|
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations.TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol.
The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. |
|
| |
| RFC 3225 | Indicating Resolver Support of DNSSEC |
| |
|
|
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. |
|
| |
| RFC 3226 | DNSSEC and IPv6 A6 aware server/resolver message size requirements |
| |
|
|
This document mandates support for EDNS0 (Extension Mechanisms forDNS) in DNS entities claiming to support either DNS SecurityExtensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updatesRFC 2535 and RFC 2874, by adding new requirements. |
|
| |
| RFC 3241 | Robust Header Compression (ROHC) over PPP |
| |
|
|
This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over thePoint-to-Point Protocol (PPP). It defines extensions to the PPPControl Protocols for IPv4 and IPv6. |
|
| |
| RFC 3261 | SIP: Session Initiation Protocol |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. |
| Date: | June 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2543 |
| Updated by: | RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3261 |
|
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types.SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. |
|
| |
| RFC 3263 | Session Initiation Protocol (SIP): Locating SIP Servers |
| |
|
|
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. |
|
| |
| RFC 3264 | An Offer/Answer Model with Session Description Protocol (SDP) |
| |
|
|
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol(SIP). |
|
| |
| RFC 3265 | Session Initiation Protocol (SIP)-Specific Event Notification |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
Concrete uses of the mechanism described in this document may be standardized in the future.
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. |
|
| |
| RFC 3270 | Multi-Protocol Label Switching (MPLS) Support of Differentiated Services |
| |
| Authors: | F. Le Faucheur, Ed., L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. |
| Date: | May 2002 |
| Formats: | txt html json |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3270 |
|
This document defines a flexible solution for support ofDifferentiated Services (Diff-Serv) over Multi-Protocol LabelSwitching (MPLS) networks.
This solution allows the MPLS network administrator to select howDiff-Serv Behavior Aggregates (BAs) are mapped onto Label SwitchedPaths (LSPs) so that he/she can best match the Diff-Serv, TrafficEngineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. |
|
| |
| RFC 3272 | Overview and Principles of Internet Traffic Engineering |
| |
| Authors: | D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. |
| Date: | May 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9522 |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3272 |
|
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. |
|
| |
| RFC 3273 | Remote Network Monitoring Management Information Base for High Capacity Networks |
| |
|
|
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 remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. |
|
| |
| RFC 3279 | Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in theInternet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs).Certificates include the public key of the named subject. |
|
| |
| RFC 3280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. AnASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 3295 | Definitions of Managed Objects for the General Switch Management Protocol (GSMP) |
| |
| Authors: | H. Sjostrand, J. Buerkle, B. Srinivasan. |
| Date: | June 2002 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3295 |
|
This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for theGeneral Switch Management Protocol (GSMP). |
|
| |
| RFC 3306 | Unicast-Prefix-based IPv6 Multicast Addresses |
| |
|
|
This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. |
|
| |
| RFC 3312 | Integration of Resource Management and Session Initiation Protocol (SIP) |
| |
|
|
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session InitiationProtocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session. |
|
| |
| RFC 3315 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8415 |
| Updated by: | RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3315 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters. |
|
| |
| RFC 3320 | Signaling Compression (SigComp) |
| |
| Authors: | R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3320 |
|
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as theSession Initiation Protocol (SIP) (RFC 3261) and the Real TimeStreaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of theSigComp message.
Decompression functionality for SigComp is provided by a UniversalDecompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951). |
|
| |
| RFC 3321 | Signaling Compression (SigComp) - Extended Operations |
| |
| Authors: | H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3321 |
|
This document describes how to implement certain mechanisms inSignaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per- message compression.
SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC3320. |
|
| |
| RFC 3325 | Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks |
| |
|
|
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. |
|
| |
| RFC 3326 | The Reason Header Field for the Session Initiation Protocol (SIP) |
| |
|
|
For creating services, it is often useful to know why a SessionInitiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", orHERFP. |
|
| |
| RFC 3327 | Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts |
| |
| Authors: | D. Willis, B. Hoeneisen. |
| Date: | December 2002 |
| Formats: | txt json html |
| Updated by: | RFC 5626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3327 |
|
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of aUniform Resource Identifier (URI), such as Contact:<sip:alice@pc33.atlanta.com&rt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. |
|
| |
| RFC 3329 | Security Mechanism Agreement for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3329 |
|
This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. |
|
| |
| RFC 3339 | Date and Time on the Internet: Timestamps |
| |
|
|
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. |
|
| |
| RFC 3344 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3363 | Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) |
| |
|
|
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. |
|
| |
| RFC 3370 | Cryptographic Message Syntax (CMS) Algorithms |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS).The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. |
|
| |
| RFC 3376 | Internet Group Management Protocol, Version 3 |
| |
| Authors: | B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. |
| Date: | October 2002 |
| Formats: | txt html json |
| Updates: | RFC 2236 |
| Updated by: | RFC 4604 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3376 |
|
This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets*only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.
This document obsoletes RFC 2236. |
|
| |
| RFC 3405 | Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures |
| |
|
|
This document is fifth in a series that is completely specified in"Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3411 | An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks |
| |
|
|
This document describes an architecture for describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are anSNMP engine containing a Message Processing Subsystem, a SecuritySubsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. |
|
| |
| RFC 3412 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes the Message Processing and Dispatching forSimple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP MessageProcessing Models, and for dispatching PDUs to SNMP applications.This document also describes one Message Processing Model - theSNMPv3 Message Processing Model. This document obsoletes RFC 2572. |
|
| |
| RFC 3414 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
|
|
This document describes the User-based Security Model (USM) forSimple Network Management Protocol (SNMP) version 3 for use in theSNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes aManagement Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. |
|
| |
| RFC 3417 | Transport Mappings for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document defines the transport of Simple Network ManagementProtocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. |
|
| |
| RFC 3427 | Change Process for the Session Initiation Protocol (SIP) |
| |
|
|
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. |
|
| |
| RFC 3428 | Session Initiation Protocol (SIP) Extension for Instant Messaging |
| |
| Authors: | B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. |
| Date: | December 2002 |
| Formats: | txt json html |
| Updated by: | RFC 8591 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3428 |
|
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
This document proposes the MESSAGE method, an extension to theSession Initiation Protocol (SIP) that allows the transfer of InstantMessages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. |
|
| |
| RFC 3435 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
|
|
This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control"intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.
Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.
The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. |
|
| |
| RFC 3436 | Transport Layer Security over Stream Control Transmission Protocol |
| |
| Authors: | A. Jungmaier, E. Rescorla, M. Tuexen. |
| Date: | December 2002 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3436 |
|
This document describes the usage of the Transport Layer Security(TLS) protocol, as defined in RFC 2246, over the Stream ControlTransmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.
The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.
Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. |
|
| |
| RFC 3443 | Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks |
| |
|
|
This document describes Time To Live (TTL) processing in hierarchicalMulti-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label StackEncoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and"pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. |
|
| |
| RFC 3458 | Message Context for Internet Mail |
| |
| Authors: | E. Burger, E. Candell, C. Eliot, G. Klyne. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 3938 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3458 |
|
This memo describes a new RFC 2822 message header, "Message-Context".This header provides information about the context and presentation characteristics of a message.
A receiving user agent (UA) may use this information as a hint to optimally present the message. |
|
| |
| RFC 3459 | Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter |
| |
|
|
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward.It can indicate how hard a gateway should try to deliver a body part.It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. |
|
| |
| RFC 3461 | Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) |
| |
|
|
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service, which allows an SMTP client to specify (a) thatDelivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. |
|
| |
| RFC 3462 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.
This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. |
|
| |
| RFC 3463 | Enhanced Mail System Status Codes |
| |
|
|
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in theDelivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. |
|
| |
| RFC 3464 | An Extensible Message Format for Delivery Status Notifications |
| |
|
|
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network(LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. |
|
| |
| RFC 3469 | Framework for Multi-Protocol Label Switching (MPLS)-based Recovery |
| |
| Authors: | V. Sharma, Ed., F. Hellstrand, Ed.. |
| Date: | February 2003 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3469 |
|
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. |
|
| |
| RFC 3470 | Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols |
| |
|
|
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language(SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. |
|
| |
| RFC 3471 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description |
| |
|
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) signaling required to support Generalized MPLS. GeneralizedMPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. |
|
| |
| RFC 3472 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions |
| |
|
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. |
|
| |
| RFC 3473 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions |
| |
| Authors: | L. Berger, Ed.. |
| Date: | January 2003 |
| Formats: | txt json html |
| Updated by: | RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003, RFC 6780, RFC 8359 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3473 |
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. |
|
| |
| RFC 3475 | Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) |
| |
|
|
Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by theIETF in the context of Generalized Multi-Protocol Label Switching(GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. |
|
| |
| RFC 3476 | Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling |
| |
|
|
The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource ReSerVationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new data objects and error codes. This document describes these extensions. |
|
| |
| RFC 3477 | Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) |
| |
| Authors: | K. Kompella, Y. Rekhter. |
| Date: | January 2003 |
| Formats: | txt json html |
| Updated by: | RFC 6107 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3477 |
|
Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to ResourceReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels(RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. |
|
| |
| RFC 3485 | The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) |
| |
| Authors: | M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. |
| Date: | February 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3485 |
|
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. |
|
| |
| RFC 3486 | Compressing the Session Initiation Protocol (SIP) |
| |
|
|
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages.It also states when it is appropriate to send compressed SIP messages to a SIP entity. |
|
| |
| RFC 3492 | Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) |
| |
|
|
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm calledBootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. |
|
| |
| RFC 3501 | INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 |
| |
| Authors: | M. Crispin. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 2060 |
| Obsoleted by: | RFC 9051 |
| Updated by: | RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3501 |
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers.These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. |
|
| |
| RFC 3502 | Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension |
| |
|
|
This document describes the multiappending extension to the InternetMessage Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.
A server which supports this extension indicates this with a capability name of "MULTIAPPEND". |
|
| |
| RFC 3515 | The Session Initiation Protocol (SIP) Refer Method |
| |
|
|
This document defines the REFER method. This Session InitiationProtocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.
In addition to the REFER method, this document defines the the refer event package and the Refer-To request header. |
|
| |
| RFC 3516 | IMAP4 Binary Content Extension |
| |
|
|
This memo defines the Binary extension to the Internet Message AccessProtocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content- transfer-encoding. |
|
| |
| RFC 3529 | Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP.An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.
This document specifies a how to use the Blocks Extensible ExchangeProtocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. |
|
| |
| RFC 3550 | RTP: A Transport Protocol for Real-Time Applications |
| |
| Authors: | H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. |
| Date: | July 2003 |
| Formats: | txt ps json pdf html |
| Obsoletes: | RFC 1889 |
| Updated by: | RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860 |
| Also: | STD 0064 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 3550 |
|
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP andRTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. |
|
| |
| RFC 3551 | RTP Profile for Audio and Video Conferences with Minimal Control |
| |
|
|
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. |
|
| |
| RFC 3552 | Guidelines for Writing RFC Text on Security Considerations |
| |
|
|
All RFCs are required to have a Security Considerations section.Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good SecurityConsiderations section. |
|
| |
| RFC 3555 | MIME Type Registration of RTP Payload Formats |
| |
|
|
This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences asMIME subtypes. Some of these may also be used for transfer modes other than RTP. |
|
| |
| RFC 3558 | RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) |
| |
|
|
This document describes the RTP payload format for Enhanced VariableRate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech.Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. |
|
| |
| RFC 3563 | Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development |
| |
|
|
This document contains the text of the agreement signed betweenISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. |
|
| |
| RFC 3564 | Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering |
| |
|
|
This document presents Service Provider requirements for support ofDifferentiated Services (Diff-Serv)-aware MPLS Traffic Engineering(DS-TE).
Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.
A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short andDiff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. |
|
| |
| RFC 3568 | Known Content Network (CN) Request-Routing Mechanisms |
| |
| Authors: | A. Barbir, B. Cain, R. Nair, O. Spatscheck. |
| Date: | July 2003 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3568 |
|
This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or beforeDecember 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layerRequest-Routing, and Application-layer Request-Routing. |
|
| |
| RFC 3572 | Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) |
| |
| Authors: | T. Ogura, M. Maruyama, T. Yoshida. |
| Date: | July 2003 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3572 |
|
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy(SONET/SDH).
This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of formingIPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. |
|
| |
| RFC 3575 | IANA Considerations for RADIUS (Remote Authentication Dial In User Service) |
| |
|
|
This document describes the IANA considerations for the RemoteAuthentication Dial In User Service (RADIUS).
This document updates RFC 2865. |
|
| |
| RFC 3579 | RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) |
| |
|
|
This document defines Remote Authentication Dial In User Service(RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. WhileEAP was originally developed for use with PPP, it is now also in use with IEEE 802.
This document updates RFC 2869. |
|
| |
| RFC 3580 | IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines |
| |
| Authors: | P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. |
| Date: | September 2003 |
| Formats: | txt json html |
| Updated by: | RFC 7268 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3580 |
|
This document provides suggestions on Remote Authentication Dial InUser Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normativeAppendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. |
|
| |
| RFC 3588 | Diameter Base Protocol |
| |
|
|
The Diameter base protocol is intended to provide an Authentication,Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by allDiameter applications. The Diameter base application needs to be supported by all Diameter implementations. |
|
| |
| RFC 3597 | Handling of Unknown DNS Resource Record (RR) Types |
| |
|
|
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. |
|
| |
| RFC 3608 | Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration |
| |
| Authors: | D. Willis, B. Hoeneisen. |
| Date: | October 2003 |
| Formats: | txt json html |
| Updated by: | RFC 5630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3608 |
|
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain. |
|
| |
| RFC 3620 | The TUNNEL Profile |
| |
|
|
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall. |
|
| |
| RFC 3630 | Traffic Engineering (TE) Extensions to OSPF Version 2 |
| |
|
|
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link StateAdvertisements. |
|
| |
| RFC 3633 | IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 |
| |
|
|
The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host ConfigurationProtocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. |
|
| |
| RFC 3640 | RTP Payload Format for Transport of MPEG-4 Elementary Streams |
| |
| Authors: | J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. |
| Date: | November 2003 |
| Formats: | txt html json |
| Updated by: | RFC 5691 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3640 |
|
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29WG11) is a working group in ISO that produced the MPEG-4 standard.MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non- multiplexed MPEG-4 elementary stream. |
|
| |
| RFC 3641 | Generic String Encoding Rules (GSER) for ASN.1 Types |
| |
|
|
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type. |
|
| |
| RFC 3656 | The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol |
| |
|
|
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.
The Mailbox Update (MUPDATE) protocol allows a group of InternetMessage Access Protocol (IMAP) or Post Office Protocol - Version 3(POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol. |
|
| |
| RFC 3658 | Delegation Signer (DS) Resource Record (RR) |
| |
|
|
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.
This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090. |
|
| |
| RFC 3679 | Unused Dynamic Host Configuration Protocol (DHCP) Option Codes |
| |
|
|
Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic HostConfiguration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future.
The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. |
|
| |
| RFC 3680 | A Session Initiation Protocol (SIP) Event Package for Registrations |
| |
|
|
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations.Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. |
|
| |
| RFC 3683 | A Practice for Revoking Posting Rights to IETF Mailing Lists |
| |
|
|
All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion.An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. |
|
| |
| RFC 3684 | Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) |
| |
| Authors: | R. Ogier, F. Templin, M. Lewis. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3684 |
|
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree(providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification ofDijkstra's algorithm. To minimize overhead, each node reports only*part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results inHELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. |
|
| |
| RFC 3693 | Geopriv Requirements |
| |
| Authors: | J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. |
| Date: | February 2004 |
| Formats: | txt json html |
| Updated by: | RFC 6280, RFC 7459 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3693 |
|
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. |
|
| |
| RFC 3694 | Threat Analysis of the Geopriv Protocol |
| |
| Authors: | M. Danley, D. Mulligan, J. Morris, J. Peterson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3694 |
|
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. |
|
| |
| RFC 3698 | Lightweight Directory Access Protocol (LDAP): Additional Matching Rules |
| |
|
|
This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. |
|
| |
| RFC 3703 | Policy Core Lightweight Directory Access Protocol (LDAP) Schema |
| |
| Authors: | J. Strassner, B. Moore, R. Moats, E. Ellesson. |
| Date: | February 2004 |
| Formats: | txt json html |
| Updated by: | RFC 4104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3703 |
|
This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that usesLightweight Directory Access Protocol (LDAP) as its access protocol.This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. |
|
| |
| RFC 3704 | Ingress Filtering for Multihomed Networks |
| |
|
|
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting theInternet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. |
|
| |
| RFC 3709 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
| Authors: | S. Santesson, R. Housley, T. Freeman. |
| Date: | February 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9399 |
| Updated by: | RFC 6170 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3709 |
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. |
|
| |
| RFC 3710 | An IESG charter |
| |
|
|
This memo provides a charter for the Internet Engineering SteeringGroup (IESG), a management function of the Internet Engineering TaskForce (IETF). It is meant to document the charter of the IESG as it is presently understood. |
|
| |
| RFC 3711 | The Secure Real-time Transport Protocol (SRTP) |
| |
|
|
This document describes the Secure Real-time Transport Protocol(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, theReal-time Transport Control Protocol (RTCP). |
|
| |
| RFC 3720 | Internet Small Computer Systems Interface (iSCSI) |
| |
|
|
This document describes a transport protocol for Internet SmallComputer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.
SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).
As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. |
|
| |
| RFC 3721 | Internet Small Computer Systems Interface (iSCSI) Naming and Discovery |
| |
| Authors: | M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. |
| Date: | April 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7143 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3721 |
|
This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. |
|
| |
| RFC 3723 | Securing Block Storage Protocols over IP |
| |
| Authors: | B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. |
| Date: | April 2004 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3723 |
|
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small ComputerSystem Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (InternetStorage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. |
|
| |
| RFC 3748 | Extensible Authentication Protocol (EAP) |
| |
|
|
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such asPoint-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.Fragmentation is not supported within EAP itself; however, individualEAP methods may support this.
This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. |
|
| |
| RFC 3749 | Transport Layer Security Protocol Compression Methods |
| |
|
|
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use withTLS, and it describes a method for the specification of additionalTLS compression methods. |
|
| |
| RFC 3755 | Legacy Resolver Compatibility for Delegation Signer (DS) |
| |
|
|
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. |
|
| |
| RFC 3762 | Telephone Number Mapping (ENUM) Service Registration for H.323 |
| |
|
|
The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone NumberMapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. |
|
| |
| RFC 3764 | enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record |
| |
|
|
This document registers an Electronic Number (ENUM) service for theSession Initiation Protocol (SIP), pursuant to the guidelines in RFC3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. |
|
| |
| RFC 3767 | Securely Available Credentials Protocol |
| |
|
|
This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support forTLS and/or DIGEST-MD5 (through BEEP). |
|
| |
| RFC 3776 | Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents |
| |
| Authors: | J. Arkko, V. Devarapalli, F. Dupont. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4877 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3776 |
|
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. |
|
| |
| RFC 3777 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 3784 | Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 3798 | Message Disposition Notification |
| |
|
|
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
|
| |
| RFC 3810 | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
|
This document updates RFC 2710, and it specifies Version 2 of theMulticast Listener Discovery Protocol (MLDv2). MLD is used by anIPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. |
|
| |
| RFC 3811 | Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management |
| |
| Authors: | T. Nadeau, Ed., J. Cucchiara, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3811 |
|
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used MultiprotocolLabel Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 3819 | Advice for Internet Subnetwork Designers |
| |
| Authors: | P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9599 |
| Also: | BCP 0089 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3819 |
|
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with theInternet architecture and the implications of their design choices on the performance and efficiency of the Internet. |
|
| |
| RFC 3821 | Fibre Channel Over TCP/IP (FCIP) |
| |
| Authors: | M. Rajagopal, E. Rodriguez, R. Weber. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3821 |
|
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. |
|
| |
| RFC 3822 | Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) |
| |
|
|
This document defines the use of Service Location Protocol version 2(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. |
|
| |
| RFC 3828 | The Lightweight User Datagram Protocol (UDP-Lite) |
| |
| Authors: | L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3828 |
|
This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. |
|
| |
| RFC 3830 | MIKEY: Multimedia Internet KEYing |
| |
| Authors: | J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4738, RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3830 |
|
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail.
Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. |
|
| |
| RFC 3832 | Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3832 |
|
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) viaDNS SRV. It defines the DNS SRV Resource Records for SLP DirectoryAgent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. |
|
| |
| RFC 3834 | Recommendations for Automatic Responses to Electronic Mail |
| |
|
|
This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders.The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. |
|
| |
| RFC 3839 | MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files |
| |
| Authors: | R. Castagno, D. Singer. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3839 |
|
This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. |
|
| |
| RFC 3843 | RObust Header Compression (ROHC): A Compression Profile for IP |
| |
| Authors: | L-E. Jonsson, G. Pelletier. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3843 |
|
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload),IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines aROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. |
|
| |
| RFC 3849 | IPv6 Address Prefix Reserved for Documentation |
| |
| Authors: | G. Huston, A. Lord, P. Smith. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 9637 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3849 |
|
To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. |
|
| |
| RFC 3852 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3856 | A Presence Event Package for the Session Initiation Protocol (SIP) |
| |
|
|
This document describes the usage of the Session Initiation Protocol(SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with theCommon Presence Profile (CPP) framework. |
|
| |
| RFC 3864 | Registration Procedures for Message Header Fields |
| |
|
|
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. |
|
| |
| RFC 3871 | Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure |
| |
|
|
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. |
|
| |
| RFC 3887 | Message Tracking Query Protocol |
| |
|
|
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. |
|
| |
| RFC 3892 | The Session Initiation Protocol (SIP) Referred-By Mechanism |
| |
|
|
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI(the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. |
|
| |
| RFC 3903 | Session Initiation Protocol (SIP) Extension for Event State Publication |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information.
The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. |
|
| |
| RFC 3920 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. |
|
| |
| RFC 3929 | Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF |
| |
|
|
This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. |
|
| |
| RFC 3931 | Layer Two Tunneling Protocol - Version 3 (L2TPv3) |
| |
|
|
This document describes "version 3" of the Layer Two TunnelingProtocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between twoIP nodes. Additional documents detail the specifics for each data link type being emulated. |
|
| |
| RFC 3943 | Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) |
| |
|
|
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. |
|
| |
| RFC 3945 | Generalized Multi-Protocol Label Switching (GMPLS) Architecture |
| |
|
|
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects(PXCs), optical cross-connects (OXCs), etc. that will use GeneralizedMulti-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extendsMPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. |
|
| |
| RFC 3953 | Telephone Number Mapping (ENUM) Service Registration for Presence Services |
| |
|
|
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning presURIs in ENUM. |
|
| |
| RFC 3956 | Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address |
| |
|
|
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. |
|
| |
| RFC 3958 | Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) |
| |
| Authors: | L. Daigle, A. Newton. |
| Date: | January 2005 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3958 |
|
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines aDynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. |
|
| |
| RFC 3961 | Encryption and Checksum Specifications for Kerberos 5 |
| |
|
|
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". |
|
| |
| RFC 3962 | Advanced Encryption Standard (AES) Encryption for Kerberos 5 |
| |
|
|
The United States National Institute of Standards and Technology(NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the oldData Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. |
|
| |
| RFC 3966 | The tel URI for Telephone Numbers |
| |
|
|
This document specifies the URI (Uniform Resource Identifier) scheme"tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. |
|
| |
| RFC 3967 | Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level |
| |
|
|
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards orIETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. |
|
| |
| RFC 3969 | The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) |
| |
|
|
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS UniformResource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. |
|
| |
| RFC 3970 | A Traffic Engineering (TE) MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for Traffic Engineered(TE) Tunnels; for example, Multi-Protocol Label Switched Paths. |
|
| |
| RFC 3971 | SEcure Neighbor Discovery (SEND) |
| |
|
|
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms forNDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. |
|
| |
| RFC 3972 | Cryptographically Generated Addresses (CGA) |
| |
|
|
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. |
|
| |
| RFC 3973 | Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Dense Mode(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. |
|
| |
| RFC 3977 | Network News Transfer Protocol (NNTP) |
| |
|
|
The Network News Transfer Protocol (NNTP) has been in use in theInternet for a decade, and remains one of the most popular protocols(by volume) in use today. This document is a replacement forRFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. |
|
| |
| RFC 3978 | IETF Rights in Contributions |
| |
|
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC2026. |
|
| |
| RFC 3979 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3981 | IRIS: The Internet Registry Information Service (IRIS) Core Protocol |
| |
|
|
This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in theExtensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. |
|
| |
| RFC 3983 | Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
This document specifies how to use the Blocks Extensible ExchangeProtocol (BEEP) as the application transport substrate for theInternet Registry Information Service (IRIS). |
|
| |
| RFC 3985 | Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture |
| |
| Authors: | S. Bryant, Ed., P. Pate, Ed.. |
| Date: | March 2005 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3985 |
|
This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. |
|
| |
| RFC 3986 | Uniform Resource Identifier (URI): Generic Syntax |
| |
|
|
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on theInternet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. |
|
| |
| RFC 4002 | IANA Registration for Enumservice 'web' and 'ft' |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2005 |
| Formats: | txt json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4002 |
|
This document registers the Enumservices 'web' and 'ft' by using theURI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). |
|
| |
| RFC 4007 | IPv6 Scoped Address Architecture |
| |
| Authors: | S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updated by: | RFC 7346 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4007 |
|
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. |
|
| |
| RFC 4012 | Routing Policy Specification Language next generation (RPSLng) |
| |
|
|
This memo introduces a new set of simple extensions to the RoutingPolicy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. |
|
| |
| RFC 4014 | Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option |
| |
| Authors: | R. Droms, J. Schnizlein. |
| Date: | February 2005 |
| Formats: | txt html json |
| Updated by: | RFC 9445 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4014 |
|
The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. |
|
| |
| RFC 4018 | Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) |
| |
| Authors: | M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. |
| Date: | April 2005 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4018 |
|
The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. |
|
| |
| RFC 4019 | RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite |
| |
|
|
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. |
|
| |
| RFC 4021 | Registration of Mail and MIME Header Fields |
| |
|
|
This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. |
|
| |
| RFC 4023 | Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) |
| |
| Authors: | T. Worster, Y. Rekhter, E. Rosen, Ed.. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updated by: | RFC 5332 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4023 |
|
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic RoutingEncapsulation). Each of these is applicable in some circumstances. |
|
| |
| RFC 4033 | DNS Security Introduction and Requirements |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 6014, RFC 6840 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4033 |
|
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that theDNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. |
|
| |
| RFC 4034 | Resource Records for the DNS Security Extensions |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4034 |
|
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
|
| |
| RFC 4035 | Protocol Modifications for the DNS Security Extensions |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 4470, RFC 6014, RFC 6840, RFC 8198, RFC 9077, RFC 9520 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4035 |
|
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
|
| |
| RFC 4036 | Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management |
| |
|
|
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 Data-over-CableService Interface Specification (DOCSIS)-compliant Cable ModemTermination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The DifferentiatedServices MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. |
|
| |
| RFC 4048 | RFC 1888 Is Obsolete |
| |
|
|
This document recommends that RFC 1888, on Open SystemsInterconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. |
|
| |
| RFC 4055 | Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric EncryptionPadding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. |
|
| |
| RFC 4071 | Structure of the IETF Administrative Support Activity (IASA) |
| |
|
|
This document describes the structure of the IETF AdministrativeSupport Activity (IASA) as an activity housed within the InternetSociety (ISOC). It defines the roles and responsibilities of theIETF Administrative Oversight Committee (IAOC), the IETFAdministrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. |
|
| |
| RFC 4072 | Diameter Extensible Authentication Protocol (EAP) Application |
| |
|
|
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. |
|
| |
| RFC 4090 | Fast Reroute Extensions to RSVP-TE for LSP Tunnels |
| |
|
|
This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. |
|
| |
| RFC 4097 | Middlebox Communications (MIDCOM) Protocol Evaluation |
| |
|
|
This document provides an evaluation of the applicability of SNMP(Simple Network Management Protocol), RSIP (Realm Specific InternetProtocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. |
|
| |
| 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 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 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 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 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 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 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 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 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 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 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 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 4202 | Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching(GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). |
|
| |
| RFC 4203 | OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 4204 | Link Management Protocol (LMP) |
| |
|
|
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. |
|
| |
| RFC 4206 | Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) |
| |
|
|
To improve scalability of Generalized Multi-Protocol Label Switching(GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a TrafficEngineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
This document describes the mechanisms to accomplish this. |
|
| |
| RFC 4207 | Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages |
| |
| Authors: | J. Lang, D. Papadimitriou. |
| Date: | October 2005 |
| Formats: | txt json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4207 |
|
This document details the Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. |
|
| |
| RFC 4209 | Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems |
| |
| Authors: | A. Fredette, Ed., J. Lang, Ed.. |
| Date: | October 2005 |
| Formats: | txt html json |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4209 |
|
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link InterfaceRequirements" described in a companion document. |
|
| |
| RFC 4210 | Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) |
| |
|
|
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. |
|
| |
| RFC 4211 | Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) |
| |
|
|
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via aRegistration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. |
|
| |
| RFC 4217 | Securing FTP with TLS |
| |
|
|
This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP SecurityExtensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for SecureSMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
This specification is in accordance with RFC 959, "File TransferProtocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". |
|
| |
| RFC 4222 | Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance |
| |
|
|
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest PathFirst (OSPF) Version 2 protocol. The methods include processing OSPFHellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. |
|
| |
| RFC 4227 | Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote ProcedureCalling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. |
|
| |
| RFC 4233 | Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | January 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 3057 |
| Updated by: | RFC 5133 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4233 |
|
This document defines a protocol for backhauling of IntegratedServices Digital Network (ISDN) Q.921 User messages over IP using theStream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller(MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
This document obsoletes RFC 3057. |
|
| |
| RFC 4235 | An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) |
| |
|
|
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved. |
|
| |
| RFC 4238 | Voice Message Routing Service |
| |
|
|
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses theVoice Profile for Internet Mail (VPIM) Directory service to lookup aVPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient.However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. |
|
| |
| RFC 4250 | The Secure Shell (SSH) Protocol Assigned Numbers |
| |
|
|
This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. |
|
| |
| RFC 4251 | The Secure Shell (SSH) Protocol Architecture |
| |
|
|
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: TheTransport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. TheUser Authentication Protocol authenticates the client to the server.The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. |
|
| |
| RFC 4252 | The Secure Shell (SSH) Authentication Protocol |
| |
|
|
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. |
|
| |
| RFC 4253 | The Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.
Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.
This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement theSSH transport layer protocol. |
|
| |
| RFC 4254 | The Secure Shell (SSH) Connection Protocol |
| |
| Authors: | T. Ylonen, C. Lonvick, Ed.. |
| Date: | January 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8308 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4254 |
|
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwardedTCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols. |
|
| |
| RFC 4261 | Common Open Policy Service (COPS) Over Transport Layer Security (TLS) |
| |
|
|
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over theInternet.
This document also updates RFC 2748 by modifying the contents of theClient-Accept message. |
|
| |
| RFC 4271 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. |
| Date: | January 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 1771 |
| Updated by: | RFC 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 4271 |
|
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list ofAutonomous Systems (ASes) that reachability information traverses.This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation ofAS paths.
This document obsoletes RFC 1771. |
|
| |
| RFC 4279 | Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) |
| |
| Authors: | P. Eronen, Ed., H. Tschofenig, Ed.. |
| Date: | December 2005 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4279 |
|
This document specifies three sets of new ciphersuites for theTransport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. |
|
| |
| RFC 4287 | The Atom Syndication Format |
| |
| Authors: | M. Nottingham, Ed., R. Sayre, Ed.. |
| Date: | December 2005 |
| Formats: | txt html json |
| Updated by: | RFC 5988 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4287 |
|
This document specifies Atom, an XML-based Web content and metadata syndication format. |
|
| |
| RFC 4291 | IP Version 6 Addressing Architecture |
| |
|
|
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.
This document obsoletes RFC 3513, "IP Version 6 AddressingArchitecture". |
|
| |
| RFC 4294 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. |
|
| |
| 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. |
|
| |
| RFC 4408 | Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |
| |
|
|
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. |
|
| |
| RFC 4412 | Communications Resource Priority for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Schulzrinne, J. Polk. |
| Date: | February 2006 |
| Formats: | txt json html |
| Updated by: | RFC 7134 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4412 |
|
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely,"Resource-Priority" and "Accept-Resource-Priority". The"Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior ofIP routers. |
|
| |
| RFC 4415 | IANA Registration for Enumservice Voice |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4415 |
|
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in theENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. |
|
| |
| RFC 4419 | Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol |
| |
| Authors: | M. Friedl, N. Provos, W. Simpson. |
| Date: | March 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8270 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4419 |
|
This memo describes a new key exchange method for the Secure Shell(SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. |
|
| |
| RFC 4429 | Optimistic Duplicate Address Detection (DAD) for IPv6 |
| |
|
|
Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) andStateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. |
|
| |
| RFC 4432 | RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. |
|
| |
| RFC 4443 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
|
|
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is theInternet Control Message Protocol for Internet Protocol version 6(IPv6). |
|
| |
| RFC 4447 | Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) |
| |
|
|
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. |
|
| |
| RFC 4448 | Encapsulation Methods for Transport of Ethernet over MPLS Networks |
| |
|
|
An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 ProtocolData Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation ofEthernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. |
|
| |
| RFC 4454 | Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | S. Singh, M. Townsley, C. Pignataro. |
| Date: | May 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4454 |
|
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use theL2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over anIP network. |
|
| |
| RFC 4456 | BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) |
| |
|
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.
This document describes the use and design of a method known as"route reflection" to alleviate the need for "full mesh" Internal BGP(IBGP).
This document obsoletes RFC 2796 and RFC 1966. |
|
| |
| RFC 4458 | Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) |
| |
| Authors: | C. Jennings, F. Audet, J. Elwell. |
| Date: | April 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8119 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4458 |
|
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. |
|
| |
| RFC 4462 | Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol |
| |
|
|
The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.
This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. |
|
| |
| RFC 4466 | Collected Extensions to IMAP4 ABNF |
| |
|
|
Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.
This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined inRFC 3501. The patterns provide for compatibility between existing and future extensions.
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. |
|
| |
| RFC 4467 | Internet Message Access Protocol (IMAP) - URLAUTH Extension |
| |
|
|
This document describes the URLAUTH extension to the Internet MessageAccess Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)(RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.
An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". |
|
| |
| RFC 4468 | Message Submission BURL Extension |
| |
|
|
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. |
|
| |
| RFC 4469 | Internet Message Access Protocol (IMAP) CATENATE Extension |
| |
|
|
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on theIMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. |
|
| |
| RFC 4486 | Subcodes for BGP Cease Notification Message |
| |
|
|
This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. |
|
| |
| RFC 4492 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. |
|
| |
| RFC 4497 | Interworking between the Session Initiation Protocol (SIP) and QSIG |
| |
|
|
This document specifies interworking between the Session InitiationProtocol (SIP) and QSIG within corporate telecommunication networks(also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) withinPrivate Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. |
|
| |
| RFC 4508 | Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method |
| |
|
|
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. |
|
| |
| RFC 4513 | Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms |
| |
|
|
This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.
This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and theSimple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.
This document, together with other documents in the LDAP TechnicalSpecification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. |
|
| |
| RFC 4531 | Lightweight Directory Access Protocol (LDAP) Turn Operation |
| |
|
|
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. |
|
| |
| RFC 4540 | NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 |
| |
| Authors: | M. Stiemerling, J. Quittek, C. Cadar. |
| Date: | May 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4540 |
|
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. |
|
| |
| RFC 4542 | Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite |
| |
|
|
RFCs 3689 and 3690 detail requirements for an EmergencyTelecommunications Service (ETS), of which an Internet EmergencyPreparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-LevelPrecedence and Preemption (MLPP) and Government EmergencyTelecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. |
|
| |
| RFC 4546 | Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces |
| |
|
|
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 Radio Frequency(RF) interfaces for systems compliant with the Data Over CableService Interface Specifications (DOCSIS). |
|
| |
| RFC 4547 | Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems |
| |
| Authors: | A. Ahmad, G. Nakanishi. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4547 |
|
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 basic set of managed objects for SimpleNetwork Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification(DOCSIS) compliant Cable Modems and Cable Modem Termination Systems.This MIB is defined as an extension to the DOCSIS Cable Device MIB.
This memo specifies a MIB module in a manner that is compliant to theStructure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. |
|
| |
| RFC 4556 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
|
|
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. |
|
| |
| RFC 4563 | The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | E. Carrara, V. Lehtovirta, K. Norrman. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4563 |
|
This memo specifies a new Type (the Key ID Information Type) for theGeneral Extension Payload in the Multimedia Internet KEYing (MIKEY)Protocol. This is used in, for example, the MultimediaBroadcast/Multicast Service specified in the Third GenerationPartnership Project. |
|
| |
| RFC 4582 | The Binary Floor Control Protocol (BFCP) |
| |
|
|
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 specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. |
|
| |
| RFC 4585 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) |
| |
|
|
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of theReal-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to theAudio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. |
|
| |
| RFC 4591 | Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. |
| Date: | August 2006 |
| Formats: | txt html json |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4591 |
|
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 tunnelFrame Relay over L2TPv3, including frame encapsulation, virtual- circuit creation and deletion, and status change notification. |
|
| |
| RFC 4594 | Configuration Guidelines for DiffServ Service Classes |
| |
|
|
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them usingDifferentiated Services Code Points (DSCPs), traffic conditioners,Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. |
|
| |
| RFC 4601 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.
This document obsoletes RFC 2362, an Experimental version of PIM-SM. |
|
| |
| RFC 4606 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
|
|
This document provides minor clarification to RFC 3946.
This document is a companion to the Generalized Multi-protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. |
|
| |
| RFC 4614 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7414 |
| Updated by: | RFC 6247 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4614 |
|
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. |
|
| |
| RFC 4616 | The PLAIN Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
This document defines a simple clear-text user/password SimpleAuthentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. |
|
| |
| RFC 4633 | Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists |
| |
|
|
Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managingInternet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. |
|
| |
| RFC 4639 | Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
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 basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of Data OverCable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.
This memo obsoletes RFC 2669. |
|
| |
| RFC 4642 | Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |
| |
|
|
This memo defines an extension to the Network News Transfer Protocol(NNTP) that allows an NNTP client and server to use Transport LayerSecurity (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. |
|
| |
| RFC 4656 | A One-way Active Measurement Protocol (OWAMP) |
| |
|
|
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources(such as GPS and CDMA). OWAMP enables the interoperability of these measurements. |
|
| |
| RFC 4660 | Functional Description of Event Notification Filtering |
| |
| Authors: | H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. |
| Date: | September 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6665 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4660 |
|
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. |
|
| |
| RFC 4680 | TLS Handshake Message for Supplemental Data |
| |
|
|
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both theTLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. |
|
| |
| RFC 4681 | TLS User Mapping Extension |
| |
|
|
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. |
|
| |
| RFC 4682 | Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | E. Nechamkin, J-F. Mule. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4682 |
|
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 basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
| |
| RFC 4697 | Observed DNS Resolution Misbehavior |
| |
|
|
This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. |
|
| |
| RFC 4701 | A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) |
| |
| Authors: | M. Stapp, T. Lemon, A. Gustafsson. |
| Date: | October 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4701 |
|
It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct ResourceRecord (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. |
|
| |
| RFC 4712 | Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman, Y. Kim. |
| Date: | October 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4712 |
|
This memo specifies two transport mappings of the Real-TimeApplication Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the SimpleNetwork Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). |
|
| |
| RFC 4716 | The Secure Shell (SSH) Public Key File Format |
| |
| Authors: | J. Galbraith, R. Thayer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4716 |
|
This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell(SSH) implementations.
In addition, this document defines a standard textual representation for SSH public key fingerprints. |
|
| |
| RFC 4719 | Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4719 |
|
This document describes the transport of Ethernet frames over theLayer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport ofEthernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. |
|
| |
| RFC 4724 | Graceful Restart Mechanism for BGP |
| |
| Authors: | S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. |
| Date: | January 2007 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Updated by: | RFC 8538 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4724 |
|
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful RestartCapability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). |
|
| |
| RFC 4731 | IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9394 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4731 |
|
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. |
|
| |
| RFC 4732 | Internet Denial-of-Service Considerations |
| |
| Authors: | M. Handley, Ed., E. Rescorla, Ed., IAB. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4732 |
|
This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. |
|
| |
| RFC 4733 | RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals |
| |
|
|
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets.It obsoletes RFC 2833.
This memo captures and expands upon the basic framework defined inRFC 2833, but retains only the most basic event codes. It sets up anIANA registry to which other event code assignments may be added.Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events.The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. |
|
| |
| RFC 4737 | Packet Reordering Metrics |
| |
| Authors: | A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4737 |
|
This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included.An appendix gives extended definitions for evaluating order with packet fragmentation. |
|
| |
| RFC 4743 | Using NETCONF over the Simple Object Access Protocol (SOAP) |
| |
|
|
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of theSimple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange ExtensibleProtocol (BEEP) bindings for NETCONF. |
|
| |
| RFC 4744 | Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
This document specifies an application protocol mapping for theNetwork Configuration Protocol (NETCONF) over the Blocks ExtensibleExchange Protocol (BEEP). |
|
| |
| RFC 4749 | RTP Payload Format for the G.729.1 Audio Codec |
| |
|
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. |
|
| |
| RFC 4757 | The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows |
| |
| Authors: | K. Jaganathan, L. Zhu, J. Brezak. |
| Date: | December 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6649 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4757 |
|
The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.
The RC4-HMAC encryption types are used to ease upgrade of existingWindows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. |
|
| |
| RFC 4760 | Multiprotocol Extensions for BGP-4 |
| |
|
|
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6,IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. |
|
| |
| RFC 4761 | Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling |
| |
|
|
Virtual Private LAN Service (VPLS), also known as Transparent LANService and Virtual Private Switched Network service, is a usefulService Provider offering. The service offers a Layer 2 VirtualPrivate Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. |
|
| |
| RFC 4769 | IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information |
| |
| Authors: | J. Livingood, R. Shockey. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4769 |
|
This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using theURI scheme 'sip' as per the IANA registration process defined in theENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. |
|
| |
| RFC 4774 | Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field |
| |
|
|
There have been a number of proposals for alternate semantics for theExplicit Congestion Notification (ECN) field in the IP header[RFC3168]. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. |
|
| |
| RFC 4776 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
|
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4785 | Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) |
| |
| Authors: | U. Blumenthal, P. Goel. |
| Date: | January 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4785 |
|
This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport LayerSecurity (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. |
|
| |
| RFC 4787 | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP |
| |
|
|
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handlingUnicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. |
|
| |
| RFC 4788 | Enhancements to RTP Payload Formats for EVRC Family Codecs |
| |
|
|
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. |
|
| |
| RFC 4791 | Calendaring Extensions to WebDAV (CalDAV) |
| |
|
|
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. |
|
| |
| RFC 4811 | OSPF Out-of-Band Link State Database (LSDB) Resynchronization |
| |
| Authors: | L. Nguyen, A. Roy, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9454 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4811 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize theirLSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.
This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. |
|
| |
| RFC 4819 | Secure Shell Public Key Subsystem |
| |
| Authors: | J. Galbraith, J. Van Dyke, J. Bright. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4819 |
|
Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution.No common key management solution exists in current implementations.This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.
A public key may also be associated with various restrictions, including a mandatory command or subsystem. |
|
| |
| RFC 4821 | Packetization Layer Path MTU Discovery |
| |
| Authors: | M. Mathis, J. Heffner. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8899 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4821 |
|
This document describes a robust method for Path MTU Discovery(PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specifyICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. |
|
| |
| RFC 4823 | FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet |
| |
|
|
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol(FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 orUN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. |
|
| |
| RFC 4844 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. |
|
| |
| RFC 4846 | Independent Submissions to the RFC Editor |
| |
| Authors: | J. Klensin, Ed., D. Thaler, Ed.. |
| Date: | July 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5744 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4846 |
|
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. |
|
| |
| RFC 4851 | The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) |
| |
|
|
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the TransportLayer Security (TLS) to establish a mutually authenticated tunnel.Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. |
|
| |
| RFC 4855 | Media Type Registration of RTP Payload Formats |
| |
|
|
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. |
|
| |
| RFC 4861 | Neighbor Discovery for IP version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson, H. Soliman. |
| Date: | September 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2461 |
| Updated by: | RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131, RFC 9685 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 4861 |
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 4862 | IPv6 Stateless Address Autoconfiguration |
| |
|
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the DuplicateAddress Detection procedure to verify the uniqueness of the addresses on a link. |
|
| |
| RFC 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4871 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4872 | RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery |
| |
|
|
This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description ofGMPLS recovery can be found in a companion document, RFC 4426. |
|
| |
| RFC 4873 | GMPLS Segment Recovery |
| |
|
|
This document describes protocol specific procedures for GMPLS(Generalized Multi-Protocol Label Switching) RSVP-TE (ResourceReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).Implications and interactions with fast reroute are also addressed.This document also updates the handling of NOTIFY_REQUEST objects. |
|
| |
| RFC 4874 | Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
|
|
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering(RSVP-TE).
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSPTunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Resource ReserVationProtocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared RiskLink Groups (SRLGs) can be excluded is also specified in this document. |
|
| |
| RFC 4875 | Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. |
| Date: | May 2007 |
| Formats: | txt html json |
| Updated by: | RFC 6510 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4875 |
|
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TELSP is outside the scope of this document. |
|
| |
| RFC 4880 | OpenPGP Message Format |
| |
|
|
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions.It does, however, discuss implementation issues necessary to avoid security flaws.
OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP. |
|
| |
| RFC 4884 | Extended ICMP to Support Multi-Part Messages |
| |
|
|
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
Multi-part messages are supported by an ICMP extension structure.The extension structure is situated at the end of the ICMP message.It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.
This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an"original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length.Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the"original datagram" field.
The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.
This memo updates RFC 792 and RFC 4443. |
|
| |
| RFC 4918 | HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. |
|
| |
| RFC 4928 | Avoiding Equal Cost Multipath Treatment in MPLS Networks |
| |
|
|
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over anMPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. |
|
| |
| RFC 4944 | Transmission of IPv6 Packets over IEEE 802.15.4 Networks |
| |
|
|
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE802.15.4 meshes. |
|
| |
| RFC 4952 | Overview and Framework for Internationalized Email |
| |
|
|
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. |
|
| |
| RFC 4954 | SMTP Service Extension for Authentication |
| |
|
|
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
This document obsoletes RFC 2554. |
|
| |
| RFC 4960 | Stream Control Transmission Protocol |
| |
|
|
This document obsoletes RFC 2960 and RFC 3309. It describes theStream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
-- optional bundling of multiple user messages into a single SCTP packet, and
-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 4964 | The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular |
| |
| Authors: | A. Allen, Ed., J. Holm, T. Hallin. |
| Date: | September 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4964 |
|
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. |
|
| |
| RFC 4969 | IANA Registration for vCard Enumservice |
| |
|
|
This memo registers the Enumservice "vCard" using the URI schemes"http" and "https". This Enumservice is to be used to refer from anENUM domain name to a vCard instance describing the user of the respective E.164 number.
Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. |
|
| |
| RFC 4974 | Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls |
| |
|
|
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequentConnections may be made. In Generalized MPLS (GMPLS) suchConnections are known as Label Switched Paths (LSPs).
This document specifies how GMPLS Resource Reservation Protocol -Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logicalCall/Connection separation.
The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. |
|
| |
| RFC 4975 | The Message Session Relay Protocol (MSRP) |
| |
|
|
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. |
|
| |
| RFC 4976 | Relay Extensions for the Message Sessions Relay Protocol (MSRP) |
| |
|
|
Two separate models for conveying instant messages have been defined.Page-mode messages stand alone and are not part of a SessionInitiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session RelayProtocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. |
|
| |
| RFC 4979 | IANA Registration for Enumservice 'XMPP' |
| |
|
|
This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers(URIs) in the context of E.164 Number Mapping (ENUM). |
|
| |
| RFC 4992 | XML Pipelining with Chunks for the Internet Registry Information Service |
| |
|
|
This document describes a simple TCP transfer protocol for theInternet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. |
|
| |
| RFC 5002 | The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) |
| |
|
|
This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS(IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destinationSIP URI of a particular SIP request. |
|
| |
| RFC 5015 | Bidirectional Protocol Independent Multicast (BIDIR-PIM) |
| |
| Authors: | M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8736, RFC 9436 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5015 |
|
This document discusses Bidirectional PIM (BIDIR-PIM), a variant ofPIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. |
|
| |
| RFC 5018 | Connection Establishment in the Binary Floor Control Protocol (BFCP) |
| |
|
|
This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). |
|
| |
| RFC 5019 | The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments |
| |
| Authors: | A. Deacon, R. Hurst. |
| Date: | September 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5019 |
|
This specification defines a profile of the Online Certificate StatusProtocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure(PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. |
|
| |
| RFC 5023 | The Atom Publishing Protocol |
| |
| Authors: | J. Gregorio, Ed., B. de hOra, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5023 |
|
The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. |
|
| |
| RFC 5024 | ODETTE File Transfer Protocol 2.0 |
| |
|
|
This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic MessageSyntax, and provides signed receipts for the acknowledgement of received files.
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used withTCP/IP, X.25, and ISDN-based networks. |
|
| |
| RFC 5026 | Mobile IPv6 Bootstrapping in Split Scenario |
| |
| Authors: | G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5026 |
|
A Mobile IPv6 node requires a Home Agent address, a home address, andIPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a MobileIPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the MobileNode. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the MobileNode's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. |
|
| |
| RFC 5028 | A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services |
| |
|
|
This document registers a Telephone Number Mapping (ENUM) service forInstant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. |
|
| |
| RFC 5029 | Definition of an IS-IS Link Attribute Sub-TLV |
| |
| Authors: | JP. Vasseur, S. Previdi. |
| Date: | September 2007 |
| Formats: | txt html json |
| Updated by: | RFC 9650 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5029 |
|
This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. |
|
| |
| RFC 5031 | A Uniform Resource Name (URN) for Emergency and Other Well-Known Services |
| |
|
|
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. |
|
| |
| RFC 5036 | LDP Specification |
| |
|
|
The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 5040 | A Remote Direct Memory Access Protocol Specification |
| |
| Authors: | R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5040 |
|
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol(ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. |
|
| |
| RFC 5041 | Direct Data Placement over Reliable Transports |
| |
| Authors: | H. Shah, J. Pinkerton, R. Recio, P. Culley. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5041 |
|
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. |
|
| |
| RFC 5042 | Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security |
| |
| Authors: | J. Pinkerton, E. Deleganes. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5042 |
|
This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct MemoryAccess Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP orRDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from LocalPeers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. |
|
| |
| RFC 5043 | Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation |
| |
|
|
This document specifies an adaptation layer to provide a Lower LayerProtocol (LLP) service for Direct Data Placement (DDP) using theStream Control Transmission Protocol (SCTP). |
|
| |
| RFC 5044 | Marker PDU Aligned Framing for TCP Specification |
| |
| Authors: | P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 6581, RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5044 |
|
Marker PDU Aligned Framing (MPA) is designed to work as an"adaptation layer" between TCP and the Direct Data Placement protocol(DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. |
|
| |
| RFC 5045 | Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) |
| |
| Authors: | C. Bestler, Ed., L. Coene. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5045 |
|
This document describes the applicability of Remote Direct MemoryAccess Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. |
|
| |
| RFC 5046 | Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) |
| |
| Authors: | M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7145 |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5046 |
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. |
|
| |
| RFC 5047 | DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5047 |
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specificDatamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and theDatamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access(RDMA)-capable IP fabrics in the future comprising TCP, the StreamControl Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. |
|
| |
| RFC 5048 | Internet Small Computer System Interface (iSCSI) Corrections and Clarifications |
| |
|
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition inRFC 3720 to serve as a companion document for the iSCSI implementers.This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. |
|
| |
| RFC 5049 | Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updates: | RFC 3486 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5049 |
|
This document describes some specifics that apply when SignalingCompression (SigComp) is applied to the Session Initiation Protocol(SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp overTCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP andSession Description Protocol (SDP) static dictionary. |
|
| |
| RFC 5054 | Using the Secure Remote Password (SRP) Protocol for TLS Authentication |
| |
| Authors: | D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5054 |
|
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. |
|
| |
| RFC 5059 | Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) |
| |
|
|
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol IndependentMulticast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. |
|
| |
| RFC 5066 | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
|
This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.This document describes extensions to the Ethernet-like InterfacesMIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004(note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the InterfacesGroup MIB and the Inverted Stack Table MIB modules. |
|
| |
| RFC 5068 | Email Submission Operations: Access and Accountability Requirements |
| |
| Authors: | C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8314 |
| Also: | BCP 0134 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5068 |
|
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet ServiceProviders. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. |
|
| |
| RFC 5070 | The Incident Object Description Exchange Format |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams(CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. |
|
| |
| RFC 5072 | IP Version 6 over PPP |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.
It also specifies the conditions for performing Duplicate AddressDetection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.
This document obsoletes RFC 2472. |
|
| |
| RFC 5077 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
|
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletesRFC 4507. |
|
| |
| RFC 5085 | Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires |
| |
| Authors: | T. Nadeau, Ed., C. Pignataro, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5085 |
|
This document describes Virtual Circuit Connectivity Verification(VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. |
|
| |
| RFC 5088 | OSPF Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5088 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within anOSPF area or within the entire OSPF routing domain. |
|
| |
| RFC 5089 | IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5089 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. |
|
| |
| RFC 5091 | Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems |
| |
|
|
This document describes the algorithms that implement Boneh-Franklin(BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-basedCryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. |
|
| |
| RFC 5092 | IMAP URL Scheme |
| |
|
|
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
This document obsoletes RFC 2192. It also updates RFC 4467. |
|
| |
| RFC 5098 | Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) |
| |
| Authors: | G. Beacham, S. Kumar, S. Channabasappa. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5098 |
|
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 basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
| |
| RFC 5102 | Information Model for IP Flow Information Export |
| |
| Authors: | J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7012 |
| Updated by: | RFC 6313 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5102 |
|
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. |
|
| |
| RFC 5104 | Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) |
| |
|
|
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
The extensions discussed are messages related to the ITU-T Rec. H.271Video Back Channel, Full Intra Request, Temporary Maximum MediaStream Bit Rate, and Temporal-Spatial Trade-off. |
|
| |
| RFC 5121 | Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks |
| |
| Authors: | B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5121 |
|
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MANCSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes theIEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. |
|
| |
| RFC 5129 | Explicit Congestion Marking in MPLS |
| |
|
|
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in anMPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. |
|
| |
| RFC 5155 | DNS Security (DNSSEC) Hashed Authenticated Denial of Existence |
| |
|
|
The Domain Name System Security (DNSSEC) Extensions introduced theNSEC resource record (RR) for authenticated denial of existence.This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. |
|
| |
| RFC 5158 | 6to4 Reverse DNS Delegation Specification |
| |
|
|
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested6to4 delegation address block. |
|
| |
| RFC 5176 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | January 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3576 |
| Updated by: | RFC 8559 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5176 |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 5177 | Network Mobility (NEMO) Extensions for Mobile IPv4 |
| |
| Authors: | K. Leung, G. Dommety, V. Narayanan, A. Petrescu. |
| Date: | April 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5177 |
|
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the MobileRouter and may not have any mobility function.
Extensions to Mobile IPv4 are introduced to support Mobile Networks. |
|
| |
| RFC 5191 | Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. |
| Date: | May 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5872 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5191 |
|
This document defines the Protocol for Carrying Authentication forNetwork Access (PANA), a network-layer transport for ExtensibleAuthentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is aUDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. |
|
| |
| RFC 5201 | Host Identity Protocol |
| |
| Authors: | R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7401 |
| Updated by: | RFC 6253 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5201 |
|
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. |
|
| |
| RFC 5213 | Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6543, RFC 7864 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5213 |
|
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. |
|
| |
| RFC 5216 | The EAP-TLS Authentication Protocol |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. TransportLayer Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. |
|
| |
| RFC 5222 | LoST: A Location-to-Service Translation Protocol |
| |
|
|
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. |
|
| |
| RFC 5228 | Sieve: An Email Filtering Language |
| |
|
|
This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 5229 | Sieve Email Filtering: Variables Extension |
| |
|
|
In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. |
|
| |
| RFC 5230 | Sieve Email Filtering: Vacation Extension |
| |
| Authors: | T. Showalter, N. Freed, Ed.. |
| Date: | January 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5230 |
|
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. |
|
| |
| RFC 5234 | Augmented BNF for Syntax Specifications: ABNF |
| |
|
|
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. |
|
| |
| RFC 5238 | Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
This document specifies the use of Datagram Transport Layer Security(DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. |
|
| |
| RFC 5243 | OSPF Database Exchange Summary List Optimization |
| |
|
|
This document describes a backward-compatible optimization for theDatabase Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reducesDatabase Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. |
|
| |
| RFC 5245 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called InteractiveConnectivity Establishment (ICE). ICE makes use of the SessionTraversal Utilities for NAT (STUN) protocol and its extension,Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session InitiationProtocol (SIP). |
|
| |
| RFC 5246 | The Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | T. Dierks, E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3268, RFC 4346, RFC 4366 |
| Obsoleted by: | RFC 8446 |
| Updates: | RFC 4492 |
| Updated by: | RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5246 |
|
This document specifies Version 1.2 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 5247 | Extensible Authentication Protocol (EAP) Key Management Framework |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated byEAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. |
|
| |
| RFC 5256 | Internet Message Access Protocol - SORT and THREAD Extensions |
| |
| Authors: | M. Crispin, K. Murchison. |
| Date: | June 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5957 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5256 |
|
This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. |
|
| |
| RFC 5263 | Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information |
| |
| Authors: | M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5263 |
|
By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the PresenceInformation Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. |
|
| |
| RFC 5267 | Contexts for IMAP4 |
| |
|
|
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. |
|
| |
| RFC 5272 | Certificate Management over CMS (CMC) |
| |
|
|
This document defines the base syntax for CMC, a CertificateManagement protocol using the Cryptographic Message Syntax (CMS).This protocol addresses two immediate needs within the InternetPublic Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key CryptographyStandard), and
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. |
|
| |
| RFC 5273 | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic MessageSyntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. |
|
| |
| RFC 5274 | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
|
This document provides a set of compliance statements about the CMC(Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. |
|
| |
| RFC 5278 | IANA Registration of Enumservices for Voice and Video Messaging |
| |
| Authors: | J. Livingood, D. Troshynski. |
| Date: | July 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5278 |
|
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and"unifmsg". Each type also registers the subtypes "sip", "sips","http", and "https", as well as the subtype "tel" for the "voicemsg" type. |
|
| |
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. |
| Date: | May 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3280, RFC 4325, RFC 4630 |
| Updated by: | RFC 6818, RFC 8398, RFC 8399, RFC 9549, RFC 9598, RFC 9608, RFC 9618 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5280 |
|
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 5281 | Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) |
| |
|
|
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. |
|
| |
| RFC 5286 | Basic Specification for IP Fast Reroute: Loop-Free Alternates |
| |
| Authors: | A. Atlas, Ed., A. Zinin, Ed.. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8518 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5286 |
|
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.This simple approach does not require any support from other routers.The extent to which this goal can be met by this specification is dependent on the topology of the network. |
|
| |
| RFC 5288 | AES Galois Counter Mode (GCM) Cipher Suites for TLS |
| |
| Authors: | J. Salowey, A. Choudhury, D. McGrew. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5288 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms. |
|
| |
| RFC 5301 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
|
|
RFC 2763 defined a simple and dynamic mechanism for routers runningIS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.
This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. |
|
| |
| RFC 5304 | IS-IS Cryptographic Authentication |
| |
|
|
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. |
|
| |
| RFC 5305 | IS-IS Extensions for Traffic Engineering |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 5307 | IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 5308 | Routing IPv6 with IS-IS |
| |
|
|
This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface addressTLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 andOSI using a single intra-domain routing protocol. |
|
| |
| RFC 5310 | IS-IS Generic Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. |
| Date: | February 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6233, RFC 6232 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5310 |
|
This document proposes an extension to Intermediate System toIntermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC5304. IS-IS is specified in International Standards Organization(ISO) 10589, with extensions to support Internet Protocol version 4(IPv4) described in RFC 1195.
Although this document has been written specifically for using theHashed Message Authentication Code (HMAC) construct along with theSecure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. |
|
| |
| RFC 5318 | The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) |
| |
| Authors: | J. Hautakorpi, G. Camarillo. |
| Date: | December 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8217 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5318 |
|
This document specifies the Session Initiation Protocol (SIP)P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individualURIs that form such a URI list. |
|
| |
| RFC 5321 | Simple Mail Transfer Protocol |
| |
|
|
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. |
|
| |
| RFC 5322 | Internet Message Format |
| |
|
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself supersededRequest For Comments (RFC) 822, "Standard for the Format of ARPAInternet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| RFC 5328 | A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) |
| |
|
|
This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. |
|
| |
| RFC 5331 | MPLS Upstream Label Assignment and Context-Specific Label Space |
| |
| Authors: | R. Aggarwal, Y. Rekhter, E. Rosen. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5331 |
|
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assignedMPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific LabelSpace". |
|
| |
| RFC 5333 | IANA Registration of Enumservices for Internet Calendaring |
| |
| Authors: | R. Mahy, B. Hoeneisen. |
| Date: | October 2009 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5333 |
|
This document registers Enumservices for Internet calendaring.Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (CalendaringExtensions to WebDAV). |
|
| |
| RFC 5334 | Ogg Media Types |
| |
| Authors: | I. Goncalves, S. Pfeiffer, C. Montgomery. |
| Date: | September 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3534 |
| Updated by: | RFC 7845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5334 |
|
This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. |
|
| |
| RFC 5340 | OSPF for IPv6 |
| |
|
|
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, Designated Router (DR) election, area support, ShortPath First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link StateAdvertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and EncapsulatingSecurity Payload (ESP).
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. |
|
| |
| RFC 5357 | A Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
The One-way Active Measurement Protocol (OWAMP), specified in RFC4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active MeasurementProtocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. |
|
| |
| RFC 5360 | A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, G. Camarillo, Ed., D. Willis. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8217 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5360 |
|
SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. |
|
| |
| RFC 5364 | Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists |
| |
| Authors: | M. Garcia-Martin, G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5364 |
|
In certain types of multimedia communications, a Session InitiationProtocol (SIP) request is distributed to a group of SIP User Agents(UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. |
|
| |
| RFC 5368 | Referring to Multiple Resources in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8262 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5368 |
|
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request.These extensions include the use of pointers to Uniform ResourceIdentifier (URI) lists in the Refer-To header field and the"multiple-refer" SIP option-tag. |
|
| |
| RFC 5382 | NAT Behavioral Requirements for TCP |
| |
| Authors: | S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. |
| Date: | October 2008 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0142 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5382 |
|
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. |
|
| |
| RFC 5384 | The Protocol Independent Multicast (PIM) Join Attribute Format |
| |
| Authors: | A. Boers, I. Wijnands, E. Rosen. |
| Date: | November 2008 |
| Formats: | txt html json |
| Updated by: | RFC 7887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5384 |
|
A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. |
|
| |
| RFC 5389 | Session Traversal Utilities for NAT (STUN) |
| |
|
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network AddressTranslator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489. |
|
| |
| RFC 5403 | RPCSEC_GSS Version 2 |
| |
|
|
This document describes version 2 of the RPCSEC_GSS protocol.Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic SecurityServices Application Programming Interface (GSS-API). |
|
| |
| RFC 5410 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 |
| |
|
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload to transport the short-term key message(STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 5415 | Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification |
| |
|
|
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. |
|
| |
| RFC 5420 | Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs.
This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. |
|
| |
| RFC 5422 | Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) |
| |
| Authors: | N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5422 |
|
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use ofEAP-FAST for dynamic provisioning. |
|
| |
| RFC 5425 | Transport Layer Security (TLS) Transport Mapping for Syslog |
| |
| Authors: | F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. |
| Date: | March 2009 |
| Formats: | txt html json |
| Updated by: | RFC 9662 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5425 |
|
This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.This document describes the security threats to syslog and how TLS can be used to counter such threats. |
|
| |
| RFC 5428 | Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | S. Channabasappa, W. De Ketelaere, E. Nechamkin. |
| Date: | April 2009 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5428 |
|
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 basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant MultimediaTerminal Adapter devices. |
|
| |
| RFC 5435 | Sieve Email Filtering: Extension for Notifications |
| |
| Authors: | A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. |
| Date: | January 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5435 |
|
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol(XMPP), or Global System for Mobile Communications (GSM) ShortMessage Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. |
|
| |
| RFC 5440 | Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
|
|
This document specifies the Path Computation Element (PCE)Communication Protocol (PCEP) for communications between a PathComputation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. |
|
| |
| RFC 5443 | LDP IGP Synchronization |
| |
| Authors: | M. Jork, A. Atlas, L. Fang. |
| Date: | March 2009 |
| Formats: | txt html json |
| Updated by: | RFC 6138 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5443 |
|
In certain networks, there is dependency on the edge-to-edge LabelSwitched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS)Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol(IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border GatewayProtocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. |
|
| |
| RFC 5444 | Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format |
| |
|
|
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. |
|
| |
| RFC 5448 | Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') |
| |
|
|
This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication ProtocolMethod for 3rd Generation Authentication and Key Agreement) method.The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd GenerationPartnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. |
|
| |
| RFC 5451 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.Any receiver-side software, such as mail filters or Mail User Agents(MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
|
| |
| RFC 5456 | IAX: Inter-Asterisk eXchange Version 2 |
| |
| Authors: | M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5456 |
|
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for theAsterisk Private Branch Exchange (PBX) and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.
IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work aroundNAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. |
|
| |
| RFC 5460 | DHCPv6 Bulk Leasequery |
| |
|
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. |
|
| |
| RFC 5470 | Architecture for IP Flow Information Export |
| |
| Authors: | G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6183 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5470 |
|
This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. |
|
| |
| RFC 5480 | Elliptic Curve Cryptography Subject Public Key Information |
| |
| Authors: | S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updates: | RFC 3279 |
| Updated by: | RFC 8813 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5480 |
|
This document specifies the syntax and semantics for the SubjectPublic Key Information field in certificates that support EllipticCurve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile", RFC 3279. |
|
| |
| RFC 5485 | Digital Signatures on Internet-Draft Documents |
| |
|
|
This document specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. |
|
| |
| RFC 5491 | GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations |
| |
|
|
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented.In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. |
|
| |
| RFC 5492 | Capabilities Advertisement with BGP-4 |
| |
|
|
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 3392. |
|
| |
| RFC 5502 | The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem |
| |
|
|
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd GenerationPartnership Project (3GPP) IMS (IP Multimedia Subsystem) between anS-CSCF (Serving Call Session Control Function) and an AS (ApplicationServer) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. |
|
| |
| RFC 5508 | NAT Behavioral Requirements for ICMP |
| |
| Authors: | P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0148 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5508 |
|
This document specifies the behavioral properties required of theNetwork Address Translator (NAT) devices in conjunction with theInternet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. |
|
| |
| RFC 5518 | Vouch By Reference |
| |
| Authors: | P. Hoffman, J. Levine, A. Hathcock. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5518 |
|
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. |
|
| |
| RFC 5531 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
|
|
This document describes the Open Network Computing (ONC) RemoteProcedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. |
|
| |
| RFC 5537 | Netnews Architecture and Protocols |
| |
|
|
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. |
|
| |
| RFC 5540 | 40 Years of RFCs |
| |
|
|
This RFC marks the 40th anniversary of the RFC document series. |
|
| |
| RFC 5543 | BGP Traffic Engineering Attribute |
| |
| Authors: | H. Ould-Brahim, D. Fedyk, Y. Rekhter. |
| Date: | May 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5543 |
|
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. |
|
| |
| RFC 5544 | Syntax for Binding Documents with Time-Stamps |
| |
|
|
This document describes an envelope that can be used to bind a file(not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors.Additional types of temporal evidence are also allowed.
The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. |
|
| |
| RFC 5545 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
|
| |
| RFC 5546 | iCalendar Transport-Independent Interoperability Protocol (iTIP) |
| |
|
|
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. |
|
| |
| RFC 5555 | Mobile IPv6 Support for Dual Stack Hosts and Routers |
| |
|
|
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where NetworkAddress Translation is present on the path between the mobile node and its home agent. |
|
| |
| RFC 5560 | A One-Way Packet Duplication Metric |
| |
|
|
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.
In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. |
|
| |
| RFC 5568 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures(namely, movement detection, new Care-of Address configuration, andBinding Update) is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.
This document updates the packet formats for the Handover Initiate(HI) and Handover Acknowledge (HAck) messages to the Mobility HeaderType. |
|
| |
| RFC 5575 | Dissemination of Flow Specification Rules |
| |
| Authors: | P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8955 |
| Updated by: | RFC 7674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5575 |
|
This document defines a new Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate(distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. |
|
| |
| RFC 5580 | Carrying Location Objects in RADIUS and Diameter |
| |
| Authors: | H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. |
| Date: | August 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8559 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5580 |
|
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service(RADIUS) and Diameter.
The distribution of location information is a privacy-sensitive task.Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. |
|
| |
| RFC 5586 | MPLS Generic Associated Channel |
| |
| Authors: | M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. |
| Date: | June 2009 |
| Formats: | txt json html |
| Updates: | RFC 3032, RFC 4385, RFC 5085 |
| Updated by: | RFC 6423, RFC 7026, RFC 7214, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5586 |
|
This document generalizes the applicability of the pseudowire (PW)Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) andMPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. |
|
| |
| RFC 5595 | The Datagram Congestion Control Protocol (DCCP) Service Codes |
| |
|
|
This document describes the usage of Service Codes by the DatagramCongestion Control Protocol, RFC 4340. It motivates the setting of aService Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC4340. |
|
| |
| RFC 5614 | Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding |
| |
|
|
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANETDesignated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways.First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. |
|
| |
| RFC 5617 | DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) |
| |
| Authors: | E. Allman, J. Fenton, M. Delany, J. Levine. |
| Date: | August 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5617 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. |
|
| |
| RFC 5621 | Message Body Handling in the Session Initiation Protocol (SIP) |
| |
|
|
This document specifies how message bodies are handled in SIP.Additionally, this document specifies SIP user agent support for MIME(Multipurpose Internet Mail Extensions) in message bodies. |
|
| |
| RFC 5622 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) |
| |
|
|
This document specifies a profile for Congestion Control Identifier4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification(ECN), while minimizing abrupt rate changes. |
|
| |
| RFC 5640 | Load-Balancing for Mesh Softwires |
| |
| Authors: | C. Filsfils, P. Mohapatra, C. Pignataro. |
| Date: | August 2009 |
| Formats: | txt json html |
| Updated by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5640 |
|
Payloads transported over a Softwire mesh service (as defined by BGPEncapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering theSoftwire can only be interpreted by the ingress and egress routers.Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two TunnelingProtocol - Version 3 (L2TPv3) over IP or Generic RoutingEncapsulation (GRE) encapsulation to what would be achieved without such encapsulation. |
|
| |
| RFC 5644 | IP Performance Metrics (IPPM): Spatial and Multicast |
| |
| Authors: | E. Stephan, L. Liang, A. Morton. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5644 |
|
The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). |
|
| |
| RFC 5648 | Multiple Care-of Addresses Registration |
| |
| Authors: | R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6089 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5648 |
|
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (NetworkMobility) Basic Support protocol as well. |
|
| |
| RFC 5652 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 5661 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, DirectoryDelegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior toNFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. |
|
| |
| RFC 5663 | Parallel NFS (pNFS) Block/Volume Layout |
| |
| Authors: | D. Black, S. Fridella, J. Glasgow. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6688 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5663 |
|
Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. |
|
| |
| RFC 5679 | Locating IEEE 802.21 Mobility Services Using DNS |
| |
|
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-definedMobility Services. Such Mobility Services are used to assist aMobile Node (MN) supporting IEEE 802.21, in handover preparation(network discovery) and handover decision (network selection). The services addressed by this document are the Media IndependentHandover Services defined in IEEE 802.21. |
|
| |
| RFC 5681 | TCP Congestion Control |
| |
|
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. |
|
| |
| RFC 5701 | IPv6 Address Specific BGP Extended Community Attribute |
| |
|
|
Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support anIPv6 Address Specific Extended Community. The lack of an IPv6Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address SpecificExtended Community, that addresses this problem. The IPv6 AddressSpecific Extended Community is similar to the IPv4 Address SpecificExtended Community, except that it carries an IPv6 address rather than an IPv4 address. |
|
| |
| RFC 5702 | Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
|
|
This document describes how to produce RSA/SHA-256 and RSA/SHA-512DNSKEY and RRSIG resource records for use in the Domain Name SystemSecurity Extensions (RFC 4033, RFC 4034, and RFC 4035). |
|
| |
| RFC 5705 | Keying Material Exporters for Transport Layer Security (TLS) |
| |
|
|
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. |
|
| |
| RFC 5709 | OSPFv2 HMAC-SHA Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updates: | RFC 2328 |
| Updated by: | RFC 7474 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5709 |
|
This document describes how the National Institute of Standards andTechnology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. |
|
| |
| RFC 5722 | Handling of Overlapping IPv6 Fragments |
| |
|
|
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. |
|
| |
| RFC 5727 | Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area |
| |
|
|
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC3427. |
|
| |
| RFC 5734 | Extensible Provisioning Protocol (EPP) Transport over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 4934. |
|
| |
| RFC 5735 | Special Use IPv4 Addresses |
| |
|
|
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by theInternet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the RegionalInternet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional InternetRegistries. It also does not address allocations or assignments ofIPv6 addresses or autonomous system numbers. |
|
| |
| RFC 5760 | RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback |
| |
| Authors: | J. Ott, J. Chesterfield, E. Schooler. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6128 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5760 |
|
This document specifies an extension to the Real-time TransportControl Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. |
|
| |
| RFC 5761 | Multiplexing RTP Data and Control Packets on a Single Port |
| |
|
|
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the SessionDescription Protocol (SDP) can be used to signal multiplexed sessions. |
|
| |
| RFC 5762 | RTP and the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion ControlProtocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. |
|
| |
| RFC 5763 | Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) |
| |
| Authors: | J. Fischl, H. Tschofenig, E. Rescorla. |
| Date: | May 2010 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5763 |
|
This document specifies how to use the Session Initiation Protocol(SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. |
|
| |
| RFC 5764 | Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) |
| |
|
|
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTPControl Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. |
|
| |
| RFC 5766 | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts(peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (TraversalUsing Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The TURN protocol was designed to be used as part of the ICE(Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. |
|
| |
| RFC 5780 | NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) |
| |
|
|
This specification defines an experimental usage of the SessionTraversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. |
|
| |
| RFC 5786 | Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions |
| |
|
|
OSPF Traffic Engineering (TE) extensions are used to advertise TELink State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID.
In order to allow other routers in a network to compute MultiprotocolLabel Switching (MPLS) Traffic Engineered Label Switched Paths (TELSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.
This document describes procedures that enhance OSPF TE to advertise a router's local addresses. |
|
| |
| RFC 5788 | IMAP4 Keyword Registry |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5788 |
|
The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. |
|
| |
| RFC 5801 | Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family |
| |
| Authors: | S. Josefsson, N. Williams. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5801 |
|
This document describes how to use a Generic Security ServiceApplication Program Interface (GSS-API) mechanism in the SimpleAuthentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. |
|
| |
| RFC 5802 | Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |
| |
|
|
The secure authentication mechanism most widely deployed and used byInternet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS).There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.
This specification describes a family of Simple Authentication andSecurity Layer (SASL; RFC 4422) authentication mechanisms called theSalted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. |
|
| |
| RFC 5804 | A Protocol for Remotely Managing Sieve Scripts |
| |
|
|
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. |
|
| |
| RFC 5810 | Forwarding and Control Element Separation (ForCES) Protocol Specification |
| |
| Authors: | A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7121, RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5810 |
|
This document specifies the Forwarding and Control Element Separation(ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in aForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654.Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). |
|
| |
| RFC 5812 | Forwarding and Control Element Separation (ForCES) Forwarding Element Model |
| |
| Authors: | J. Halpern, J. Hadi Salim. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7408 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5812 |
|
This document defines the forwarding element (FE) model used in theForwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. |
|
| |
| RFC 5818 | Data Channel Status Confirmation Extensions for the Link Management Protocol |
| |
| Authors: | D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. |
| Date: | April 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5818 |
|
This document defines simple additions to the Link ManagementProtocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-SwitchingRouters (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found.As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. |
|
| |
| RFC 5820 | Extensions to OSPF to Support Mobile Ad Hoc Networking |
| |
| Authors: | A. Roy, Ed., M. Chandra, Ed.. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7137 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5820 |
|
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-OverlappingRelay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. |
|
| |
| RFC 5830 | GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. |
|
| |
| RFC 5831 | GOST R 34.11-94: Hash Function Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. |
|
| |
| RFC 5832 | GOST R 34.10-2001: Digital Signature Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (calledGOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification. |
|
| |
| RFC 5838 | Support of Address Families in OSPFv3 |
| |
|
|
This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions toOSPFv3 for supporting multiple AFs. |
|
| |
| RFC 5864 | DNS SRV Resource Records for AFS |
| |
|
|
This document specifies how to use DNS (Domain Name Service) SRV RRs(Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. |
|
| |
| RFC 5878 | Transport Layer Security (TLS) Authorization Extensions |
| |
|
|
This document specifies authorization extensions to the TransportLayer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language(SAML) assertions, is exchanged in the supplemental data handshake message. |
|
| |
| RFC 5880 | Bidirectional Forwarding Detection (BFD) |
| |
|
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. |
|
| |
| RFC 5884 | Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. |
| Date: | June 2010 |
| Formats: | txt html json |
| Updates: | RFC 1122 |
| Updated by: | RFC 7726 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5884 |
|
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label SwitchedPath (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination ofLSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability ofBFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. |
|
| |
| RFC 5885 | Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) |
| |
|
|
This document describes Connectivity Verification (CV) Types usingBidirectional Forwarding Detection (BFD) with Virtual CircuitConnectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. |
|
| |
| RFC 5888 | The Session Description Protocol (SDP) Grouping Framework |
| |
|
|
In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. |
|
| |
| RFC 5892 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) |
| |
|
|
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).
It is part of the specification of Internationalizing Domain Names inApplications 2008 (IDNA2008). |
|
| |
| RFC 5905 | Network Time Protocol Version 4: Protocol and Algorithms Specification |
| |
|
|
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.NTPv4 includes a modified protocol header to accommodate the InternetProtocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. |
|
| |
| RFC 5911 | New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME |
| |
|
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates thoseASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5912 | New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) |
| |
|
|
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The currentASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5918 | Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) |
| |
| Authors: | R. Asati, I. Minei, B. Thomas. |
| Date: | August 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5918 |
|
The Label Distribution Protocol (LDP) specification for the WildcardForward Equivalence Class (FEC) element has several limitations.This document addresses those limitations by defining a TypedWildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. |
|
| |
| RFC 5921 | A Framework for MPLS in Transport Networks |
| |
| Authors: | M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6215, RFC 7274 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5921 |
|
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance(OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of theMPLS-TP.
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 5928 | Traversal Using Relays around NAT (TURN) Resolution Mechanism |
| |
|
|
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a TraversalUsing Relays around NAT (TURN) allocation. |
|
| |
| RFC 5929 | Channel Bindings for TLS |
| |
| Authors: | J. Altman, N. Williams, L. Zhu. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5929 |
|
This document defines three channel binding types for Transport LayerSecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding).
Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. |
|
| |
| RFC 5931 | Extensible Authentication Protocol (EAP) Authentication Using Only a Password |
| |
|
|
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. |
|
| |
| RFC 5933 | Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | V. Dolmatov, Ed., A. Chuprina, I. Ustinov. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6944 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5933 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the DomainName System Security Extensions (DNSSEC). |
|
| |
| RFC 5936 | DNS Zone Transfer Protocol (AXFR) |
| |
|
|
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. |
|
| |
| RFC 5939 | Session Description Protocol (SDP) Capability Negotiation |
| |
|
|
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.
The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.
The document defines a general SDP Capability Negotiation framework.It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. |
|
| |
| RFC 5953 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 5959 | Algorithms for Asymmetric Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData,EnvelopedData, EncryptedData, AuthenticatedData, andAuthEnvelopedData. |
|
| |
| RFC 5960 | MPLS Transport Profile Data Plane Architecture |
| |
| Authors: | D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5960 |
|
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network. |
|
| |
| RFC 5961 | Improving TCP's Robustness to Blind In-Window Attacks |
| |
| Authors: | A. Ramaiah, R. Stewart, M. Dalal. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5961 |
|
TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 orBorder Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.
Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed.Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. |
|
| |
| RFC 5965 | An Extensible Format for Email Feedback Reports |
| |
| Authors: | Y. Shafranovich, J. Levine, M. Kucherawy. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6650 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5965 |
|
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used inInternet email. |
|
| |
| RFC 5985 | HTTP-Enabled Location Delivery (HELD) |
| |
|
|
This document defines a Layer 7 Location Configuration Protocol (L7LCP) and describes the use of HTTP and HTTP/TLS as transports for theL7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. |
|
| |
| RFC 5996 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
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 document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. |
|
| |
| RFC 6012 | Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog |
| |
|
|
This document describes the transport of syslog messages over theDatagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. |
|
| |
| RFC 6014 | Cryptographic Algorithm Identifier Allocation for DNSSEC |
| |
|
|
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required forDNSSEC implementations. |
|
| |
| RFC 6033 | Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, andAuthEnvelopedData. |
|
| |
| RFC 6040 | Tunnelling of Explicit Congestion Notification |
| |
|
|
This document redefines how the explicit congestion notification(ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301IPsec ECN processing. On decapsulation, it updates both RFC 3168 andRFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification --PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. |
|
| |
| RFC 6042 | Transport Layer Security (TLS) Authorization Using KeyNote |
| |
|
|
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security(TLS) Handshake Protocol, according to guidelines in RFC 5878.Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. |
|
| |
| RFC 6043 | MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
|
|
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing.Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. |
|
| |
| RFC 6049 | Spatial Composition of Metrics |
| |
| Authors: | A. Morton, E. Stephan. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6049 |
|
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. |
|
| |
| RFC 6053 | Implementation Report for Forwarding and Control Element Separation (ForCES) |
| |
| Authors: | E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. |
| Date: | November 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6984 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6053 |
|
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.
This document is an implementation report for the ForCES Protocol,Model, and the Stream Control Transmission Protocol-based TransportMapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. |
|
| |
| RFC 6066 | Transport Layer Security (TLS) Extensions: Extension Definitions |
| |
|
|
This document provides specifications for existing TLS extensions.It is a companion document for RFC 5246, "The Transport LayerSecurity (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. |
|
| |
| RFC 6073 | Segmented Pseudowire |
| |
| Authors: | L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6723, RFC 7267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6073 |
|
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. |
|
| |
| RFC 6083 | Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Seggelmann, E. Rescorla. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6083 |
|
This document describes the usage of the Datagram Transport LayerSecurity (DTLS) protocol over the Stream Control TransmissionProtocol (SCTP).
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. |
|
| |
| RFC 6084 | General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | X. Fu, C. Dickmann, J. Crowcroft. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6084 |
|
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over theStream Control Transmission Protocol (SCTP) and Datagram TransportLayer Security (DTLS). |
|
| |
| RFC 6105 | IPv6 Router Advertisement Guard |
| |
| Authors: | E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. |
| Date: | February 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7113 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6105 |
|
Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. |
|
| |
| RFC 6110 | Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content |
| |
|
|
This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG),Schematron, and Schematron and Document Schema Renaming Language(DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.Procedures for schema-based validation of such documents are also discussed. |
|
| |
| RFC 6120 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document definesXMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. |
|
| |
| RFC 6126 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. |
|
| |
| RFC 6130 | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
|
|
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). |
|
| |
| RFC 6145 | IP/ICMP Translation Algorithm |
| |
|
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 2765. |
|
| |
| RFC 6155 | Use of Device Identity in HTTP-Enabled Location Delivery (HELD) |
| |
| Authors: | J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6915 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6155 |
|
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. |
|
| |
| RFC 6158 | RADIUS Design Guidelines |
| |
|
|
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). |
|
| |
| RFC 6164 | Using 127-Bit IPv6 Prefixes on Inter-Router Links |
| |
| Authors: | M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. |
| Date: | April 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6547 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6164 |
|
On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. |
|
| |
| RFC 6176 | Prohibiting Secure Sockets Layer (SSL) Version 2.0 |
| |
|
|
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport LayerSecurity (TLS). |
|
| |
| RFC 6186 | Use of SRV Records for Locating Email Submission/Access Services |
| |
|
|
This specification describes how SRV records can be used to locate email services. |
|
| |
| RFC 6205 | Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers |
| |
|
|
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.Global wavelength semantics are not considered.
In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the DenseWavelength Division Multiplexing (DWDM) and Coarse WavelengthDivision Multiplexing (CWDM) grids defined by the InternationalTelecommunication Union Telecommunication Standardization Sector.The label format defined in this document can be used in GMPLS signaling and routing protocols. |
|
| |
| RFC 6231 | An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework |
| |
| Authors: | S. McGlashan, T. Melanchuk, C. Boulton. |
| Date: | May 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6623 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6231 |
|
This document defines a Media Control Channel Framework Package forInteractive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. |
|
| |
| RFC 6232 | Purge Originator Identification TLV for IS-IS |
| |
|
|
At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge.This makes it difficult to locate the source IS.
To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normalLink State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.
This document updates RFC 5301, RFC 5304, and RFC 5310. |
|
| |
| RFC 6241 | Network Configuration Protocol (NETCONF) |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletesRFC 4741. |
|
| |
| RFC 6282 | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks |
| |
|
|
This document updates RFC 4944, "Transmission of IPv6 Packets overIEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power WirelessPersonal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope.This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. |
|
| |
| RFC 6292 | Requirements for a Working Group Charter Tool |
| |
|
|
The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. |
|
| |
| RFC 6320 | Protocol for Access Node Control Mechanism in Broadband Networks |
| |
| Authors: | S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed.. |
| Date: | October 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7256 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6320 |
|
This document describes the Access Node Control Protocol (ANCP).ANCP operates between a Network Access Server (NAS) and an AccessNode (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the baseANCP protocol, this document specifies capabilities for DigitalSubscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.
ANCP is based on the General Switch Management Protocol version 3(GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. |
|
| |
| RFC 6321 | xCal: The XML Format for iCalendar |
| |
|
|
This specification defines "xCal", an XML format for iCalendar data. |
|
| |
| RFC 6325 | Routing Bridges (RBridges): Base Protocol Specification |
| |
| Authors: | R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. |
| Date: | July 2011 |
| Formats: | txt html json |
| Updated by: | RFC 6327, RFC 6439, RFC 7172, RFC 7177, RFC 7357, RFC 7179, RFC 7180, RFC 7455, RFC 7780, RFC 7783, RFC 8139, RFC 8249, RFC 8361, RFC 8377 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6325 |
|
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.
RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.
The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges(rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. |
|
| |
| RFC 6327 | Routing Bridges (RBridges): Adjacency |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU(Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. |
|
| |
| RFC 6333 | Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion |
| |
| Authors: | A. Durand, R. Droms, J. Woodyatt, Y. Lee. |
| Date: | August 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7335 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6333 |
|
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). |
|
| |
| RFC 6347 | Datagram Transport Layer Security Version 1.2 |
| |
|
|
This document specifies version 1.2 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. This document updatesDTLS 1.0 to work with TLS version 1.2. |
|
| |
| RFC 6350 | vCard Format Specification |
| |
|
|
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. |
|
| |
| RFC 6351 | xCard: vCard XML Representation |
| |
|
|
This document defines the XML schema of the vCard data format. |
|
| |
| RFC 6352 | CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. |
|
| |
| RFC 6353 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of anSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 6363 | Forward Error Correction (FEC) Framework |
| |
| Authors: | M. Watson, A. Begen, V. Roca. |
| Date: | October 2011 |
| Formats: | txt html json |
| Updated by: | RFC 8680 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6363 |
|
This document describes a framework for using Forward ErrorCorrection (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content DeliveryProtocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. |
|
| |
| RFC 6367 | Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) |
| |
|
|
This document specifies forty-two cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. |
|
| |
| RFC 6368 | Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7606, RFC 9494 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6368 |
|
This document defines protocol extensions and procedures for BGPProvider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. |
|
| |
| RFC 6371 | Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks |
| |
| Authors: | I. Busi, Ed., D. Allan, Ed.. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6435 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6371 |
|
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS TrafficEngineering (MPLS-TE) and pseudowire (PW) data-plane architectures.
This document describes a framework to support a comprehensive set ofOperations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6374 | Packet Loss and Delay Measurement for MPLS Networks |
| |
| Authors: | D. Frost, S. Bryant. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6374 |
|
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. |
|
| |
| RFC 6376 | DomainKeys Identified Mail (DKIM) Signatures |
| |
|
|
DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.
This memo obsoletes RFC 4871 and RFC 5672. |
|
| |
| RFC 6378 | MPLS Transport Profile (MPLS-TP) Linear Protection |
| |
|
|
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationsStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
This document addresses the functionality described in the MPLS-TPSurvivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection StateCoordination for linear protection, as described in that document. |
|
| |
| RFC 6388 | Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| Authors: | IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6388 |
|
This document describes extensions to the Label Distribution Protocol(LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.These extensions are also referred to as multipoint LDP. MultipointLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks(L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. |
|
| |
| RFC 6391 | Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network |
| |
| Authors: | S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6391 |
|
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal CostMultiple Paths (ECMPs) that exist in the packet switched network.Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.
This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires.The mechanism uses an additional label in the MPLS label stack. |
|
| |
| RFC 6409 | Message Submission for Mail |
| |
|
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay is unaffected, and continues to use SMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
| |
| RFC 6424 | Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels |
| |
|
|
This document describes methods for performing LSP ping (specified inRFC 4379) traceroute over MPLS tunnels and for traceroute of stitchedMPLS Label Switched Paths (LSPs). The techniques outlined in RFC4379 are insufficient to perform traceroute Forwarding EquivalencyClass (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a newTLV that, along with other procedures outlined in this document, can be used to trace such LSPs. |
|
| |
| RFC 6427 | MPLS Fault Management Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6427 |
|
This document specifies Operations, Administration, and Maintenance(OAM) messages to indicate service disruptive conditions for MPLS- based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. |
|
| |
| RFC 6428 | Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile |
| |
| Authors: | D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6428 |
|
Continuity Check, Proactive Connectivity Verification, and RemoteDefect Indication functionalities are required for MPLS TransportProfile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments ContinuityCheck in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, orSection.
This document specifies specific extensions to BidirectionalForwarding Detection (BFD) and methods for proactive ContinuityCheck, Continuity Verification, and Remote Defect Indication forMPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. |
|
| |
| RFC 6439 | Routing Bridges (RBridges): Appointed Forwarders |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to IntermediateSystem) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multipleRBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called"Appointed Forwarders", with the intent that native traffic in eachVLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the AppointedForwarder mechanism; thus, it updates RFC 6325. |
|
| |
| RFC 6442 | Location Conveyance for the Session Initiation Protocol |
| |
|
|
This document defines an extension to the Session Initiation Protocol(SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of theLocation Target. |
|
| |
| RFC 6443 | Framework for Emergency Calling Using Internet Multimedia |
| |
| Authors: | B. Rosen, H. Schulzrinne, J. Polk, A. Newton. |
| Date: | December 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7852 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6443 |
|
The IETF has standardized various aspects of placing emergency calls.This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. |
|
| |
| RFC 6455 | The WebSocket Protocol |
| |
|
|
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., usingXMLHttpRequest or <iframe&rt;s and long polling). |
|
| |
| RFC 6460 | Suite B Profile for Transport Layer Security (TLS) |
| |
|
|
The United States government has published guidelines for "NSA SuiteB Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. |
|
| |
| RFC 6478 | Pseudowire Status for Static Pseudowires |
| |
|
|
This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allowsPW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection(BFD) is used to convey PW status-signaling information. |
|
| |
| RFC 6487 | A Profile for X.509 PKIX Resource Certificates |
| |
|
|
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and CertificateRevocation List (CRL) syntax in the Resource Public KeyInfrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. |
|
| |
| RFC 6488 | Signed Object Template for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | M. Lepinski, A. Chi, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 9589 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6488 |
|
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. |
|
| |
| RFC 6513 | Multicast in MPLS/BGP IP VPNs |
| |
|
|
In order for IP multicast traffic within a BGP/MPLS IP VPN (VirtualPrivate Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN ServiceProvider. These protocols and procedures are specified in this document. |
|
| |
| RFC 6514 | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
| Authors: | R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 6515, RFC 6625, RFC 7385, RFC 7441, RFC 7582, RFC 7899, RFC 7900, RFC 7902, RFC 7988, RFC 8534, RFC 9081, RFC 9573 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6514 |
|
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGPIP VPNs, as specified in RFC 6513. |
|
| |
| RFC 6520 | Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension |
| |
| Authors: | R. Seggelmann, M. Tuexen, M. Williams. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6520 |
|
This document describes the Heartbeat Extension for the TransportLayer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. |
|
| |
| RFC 6522 | The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
This memo obsoletes "The Multipart/Report Content Type for theReporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". |
|
| |
| RFC 6550 | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks |
| |
| Authors: | T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. |
| Date: | March 2012 |
| Formats: | txt json html |
| Updated by: | RFC 9008, RFC 9010, RFC 9685 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6550 |
|
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside theLLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks(RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. |
|
| |
| RFC 6553 | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams |
| |
|
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes theRPL Option for use among RPL routers to include such routing information. |
|
| |
| RFC 6572 | RADIUS Support for Proxy Mobile IPv6 |
| |
| Authors: | F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. |
| Date: | June 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8044 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6572 |
|
This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-basedAAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. |
|
| |
| RFC 6591 | Authentication Failure Reporting Using the Abuse Reporting Format |
| |
|
|
This memo registers an extension report type for the Abuse ReportingFormat (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. |
|
| |
| RFC 6613 | RADIUS over TCP |
| |
|
|
The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over theTransmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security(RADIUS/TLS). It permits TCP to be used as a transport protocol forRADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. |
|
| |
| RFC 6614 | Transport Layer Security (TLS) Encryption for RADIUS |
| |
| Authors: | S. Winter, M. McCauley, S. Venaas, K. Wierenga. |
| Date: | May 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6614 |
|
This document specifies a transport profile for RADIUS usingTransport Layer Security (TLS) over TCP as the transport protocol.This enables dynamic trust relationships between RADIUS servers. |
|
| |
| RFC 6625 | Wildcards in Multicast VPN Auto-Discovery Routes |
| |
|
|
In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network.The base specifications for MVPN define BGP multicast VPN "auto- discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto- discovery route can refer to multiple customer flows or even to all customer flows. |
|
| |
| RFC 6638 | Scheduling Extensions to CalDAV |
| |
|
|
This document defines extensions to the Calendaring Extensions toWebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. |
|
| |
| RFC 6665 | SIP-Specific Event Notification |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. |
|
| |
| RFC 6679 | Explicit Congestion Notification (ECN) for RTP over UDP |
| |
| Authors: | M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. |
| Date: | August 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8311 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6679 |
|
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT(STUN) extension used in the optional initialisation method usingInteractive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. |
|
| |
| RFC 6698 | The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA |
| |
|
|
Encrypted communication on the Internet often uses Transport LayerSecurity (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. |
|
| |
| RFC 6702 | Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules |
| |
|
|
The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. |
|
| |
| RFC 6712 | Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) |
| |
|
|
This document describes how to layer the Certificate ManagementProtocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. |
|
| |
| RFC 6716 | Definition of the Opus Audio Codec |
| |
| Authors: | JM. Valin, K. Vos, T. Terriberry. |
| Date: | September 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8251 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6716 |
|
This document defines the Opus interactive speech and audio codec.Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and theModified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. |
|
| |
| RFC 6720 | The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) |
| |
|
|
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for theLabel Distribution Protocol (LDP).
This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. |
|
| |
| RFC 6733 | Diameter Base Protocol |
| |
|
|
The Diameter base protocol is intended to provide an Authentication,Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by allDiameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. |
|
| |
| RFC 6739 | Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol |
| |
| Authors: | H. Schulzrinne, H. Tschofenig. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6739 |
|
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriatePublic Safety Answering Point (PSAP) for emergency services.
The <mapping&rt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform ResourceIdentifier (URI) or set of URIs for a given service.
This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping&rt; elements between two entities. Exchanging cached <mapping&rt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping&rt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. |
|
| |
| RFC 6749 | The OAuth 2.0 Authorization Framework |
| |
|
|
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. |
|
| |
| RFC 6750 | The OAuth 2.0 Authorization Framework: Bearer Token Usage |
| |
|
|
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. |
|
| |
| RFC 6754 | Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect |
| |
|
|
A Protocol Independent Multicast (PIM) router uses the Reverse PathForwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources.This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. |
|
| |
| RFC 6756 | Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines |
| |
| Authors: | S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. |
| Date: | September 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3356 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6756 |
|
This document provides guidance to aid in the understanding of collaboration on standards development between the TelecommunicationStandardization Sector of the International Telecommunication Union(ITU-T) and the Internet Engineering Task Force (IETF) of theInternet Society (ISOC). It is an update of and obsoletes RFC 3356.The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T ASeries Supplement 3 (07/2012).
Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to theITU-T A-Series of Recommendations. |
|
| |
| RFC 6757 | Access Network Identifier (ANI) Option for Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 7563 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6757 |
|
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. |
|
| |
| RFC 6763 | DNS-Based Service Discovery |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6763 |
|
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standardDNS queries. This mechanism is referred to as DNS-based ServiceDiscovery, or DNS-SD. |
|
| |
| RFC 6775 | Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
|
|
The IETF work in IPv6 over Low-power Wireless Personal Area Network(6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. |
|
| |
| RFC 6790 | The Use of Entropy Labels in MPLS Forwarding |
| |
|
|
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing acrossMPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. |
|
| |
| RFC 6810 | The Resource Public Key Infrastructure (RPKI) to Router Protocol |
| |
| Authors: | R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6810 |
|
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. |
|
| |
| RFC 6811 | BGP Prefix Origin Validation |
| |
| Authors: | P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8481, RFC 8893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6811 |
|
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AutonomousSystem (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. |
|
| |
| RFC 6826 | Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| Authors: | IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. |
| Date: | January 2013 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6826 |
|
Consider an IP multicast tree, constructed by Protocol IndependentMulticast (PIM), that needs to pass through an MPLS domain in whichMultipoint LDP (mLDP) point-to-multipoint and/or multipoint-to- multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. |
|
| |
| RFC 6830 | The Locator/ID Separation Protocol (LISP) |
| |
|
|
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop. |
|
| |
| RFC 6839 | Additional Media Type Structured Syntax Suffixes |
| |
|
|
A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json","+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. |
|
| |
| RFC 6840 | Clarifications and Implementation Notes for DNS Security (DNSSEC) |
| |
|
|
This document is a collection of technical clarifications to the DNSSecurity (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.
This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of theDNSSEC specification. |
|
| |
| RFC 6870 | Pseudowire Preferential Forwarding Status Bit |
| |
|
|
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured betweenProvider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes inMulti-Segment Pseudowire (MS-PW) applications.
In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.
In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.
Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV. |
|
| |
| RFC 6873 | Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) |
| |
| Authors: | G. Salgueiro, V. Gurbani, A. B. Roach. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7355 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6873 |
|
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. |
|
| |
| RFC 6881 | Best Current Practice for Communications Services in Support of Emergency Calling |
| |
|
|
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. |
|
| |
| RFC 6887 | Port Control Protocol (PCP) |
| |
|
|
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by aNetwork Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. |
|
| |
| RFC 6890 | Special-Purpose IP Address Registries |
| |
|
|
This memo reiterates the assignment of an IPv4 address block(192.0.0.0/24) to IANA. It also instructs IANA to restructure itsIPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special- purpose address blocks, maintaining a common set of information regarding each address block.
This memo obsoletes RFCs 4773, 5156, 5735, and 5736. |
|
| |
| RFC 6926 | DHCPv4 Bulk Leasequery |
| |
| Authors: | K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. |
| Date: | April 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6926 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. |
|
| |
| RFC 6951 | UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
| |
|
|
This document describes a simple method of encapsulating StreamControl Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacyNATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.
This document covers only end-hosts and not tunneling (egress or ingress) endpoints. |
|
| |
| RFC 6960 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
|
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CertificateRevocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. |
|
| |
| RFC 6987 | OSPF Stub Router Advertisement |
| |
| Authors: | A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. |
| Date: | September 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 3137 |
| Updated by: | RFC 8770 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6987 |
|
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.
This document obsoletes RFC 3137. |
|
| |
| RFC 7001 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7030 | Enrollment over Secure Transport |
| |
|
|
This document profiles certificate enrollment for clients usingCertificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport(EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority(CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. |
|
| |
| RFC 7050 | Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis |
| |
| Authors: | T. Savolainen, J. Korhonen, D. Wing. |
| Date: | November 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7050 |
|
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-knownIPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. |
|
| |
| RFC 7084 | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 RapidDeployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-StackLite (DS-Lite) are covered in the document. The document obsoletesRFC 6204. |
|
| |
| RFC 7110 | Return Path Specified Label Switched Path (LSP) Ping |
| |
| Authors: | M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7110 |
|
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. |
|
| |
| RFC 7121 | High Availability within a Forwarding and Control Element Separation (ForCES) Network Element |
| |
| Authors: | K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. |
| Date: | February 2014 |
| Formats: | txt html json |
| Updates: | RFC 5810 |
| Updated by: | RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7121 |
|
This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) NetworkElement (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism. |
|
| |
| RFC 7139 | GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks |
| |
| Authors: | F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. |
| Date: | March 2014 |
| Formats: | txt html json |
| Updates: | RFC 4328 |
| Updated by: | RFC 7892 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7139 |
|
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channelData Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.
This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. |
|
| |
| RFC 7140 | LDP Extensions for Hub and Spoke Multipoint Label Switched Path |
| |
| Authors: | L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. |
| Date: | March 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7140 |
|
This document introduces a hub and spoke multipoint (HSMP) LabelSwitched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed. |
|
| |
| RFC 7153 | IANA Registries for BGP Extended Communities |
| |
|
|
This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the"IANA Considerations" sections of future protocol specifications.This document updates RFC 4360 and RFC 5701. |
|
| |
| RFC 7170 | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
| Authors: | H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9427 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7170 |
|
This document defines the Tunnel Extensible Authentication Protocol(TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using theTransport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. |
|
| |
| RFC 7175 | Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support |
| |
| Authors: | V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7175 |
|
This document specifies use of the Bidirectional Forwarding Detection(BFD) protocol in Routing Bridge (RBridge) campuses based on theRBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.
BFD is a widely deployed Operations, Administration, and Maintenance(OAM) mechanism in IP and MPLS networks, using UDP and AssociatedChannel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL. |
|
| |
| RFC 7177 | Transparent Interconnection of Lots of Links (TRILL): Adjacency |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network(LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System(IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325. |
|
| |
| RFC 7178 | Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support |
| |
| Authors: | D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7978 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7178 |
|
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the TransparentInterconnection of Lots of Links (TRILL) protocol. |
|
| |
| RFC 7179 | Transparent Interconnection of Lots of Links (TRILL): Header Extension |
| |
| Authors: | D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updates: | RFC 6325 |
| Updated by: | RFC 7780 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7179 |
|
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILLHeader extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325. |
|
| |
| RFC 7181 | The Optimized Link State Routing Protocol Version 2 |
| |
|
|
This specification describes version 2 of the Optimized Link StateRouting Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs). |
|
| |
| RFC 7186 | Security Threats for the Neighborhood Discovery Protocol (NHDP) |
| |
| Authors: | J. Yi, U. Herberg, T. Clausen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7985 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7186 |
|
This document analyzes common security threats of the NeighborhoodDiscovery Protocol (NHDP) and describes their potential impacts onMobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described. |
|
| |
| RFC 7188 | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs |
| |
|
|
This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updatesRFC 7181 (OLSRv2) and RFC 6130 (NHDP). |
|
| |
| RFC 7208 | Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |
| |
|
|
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrativeManagement Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.
This document obsoletes RFC 4408. |
|
| |
| RFC 7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" UniformResource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. |
|
| |
| RFC 7240 | Prefer Header for HTTP |
| |
|
|
This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request. |
|
| |
| RFC 7241 | The IEEE 802/IETF Relationship |
| |
| Authors: | S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. |
| Date: | July 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4441 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7241 |
|
This document describes the standardization cooperation betweenProject 802 of the Institute of Electrical and Electronics Engineers(IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.
Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication. |
|
| |
| RFC 7246 | Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context |
| |
| Authors: | IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. |
| Date: | June 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7246 |
|
An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non- label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IPMDT, then convert it to an MPLS Multipoint Label Switched Path(MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region.Other documents specify the procedures for building such a hybridMDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label DistributionProtocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN. |
|
| |
| RFC 7252 | The Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained(e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks(6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.
CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs andInternet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. |
|
| |
| RFC 7265 | jCal: The JSON Format for iCalendar |
| |
| Authors: | P. Kewisch, C. Daboo, M. Douglass. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7529 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7265 |
|
This specification defines "jCal", a JSON format for iCalendar data.The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications. |
|
| |
| RFC 7268 | RADIUS Attributes for IEEE 802 Networks |
| |
|
|
RFC 3580 provides guidelines for the use of the Remote AuthenticationDial-In User Service (RADIUS) within IEEE 802 local area networks(LANs). This document defines additional attributes for use withinIEEE 802 networks and clarifies the usage of the EAP-Key-NameAttribute and the Called-Station-Id Attribute. This document updatesRFCs 3580 and 4072. |
|
| |
| RFC 7271 | MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators |
| |
| Authors: | J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 6378 |
| Updated by: | RFC 8234 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7271 |
|
This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.
This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and AutomaticProtection Switching (APS) mode.
This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.
This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. |
|
| |
| RFC 7274 | Allocating and Retiring Special-Purpose MPLS Labels |
| |
| Authors: | K. Kompella, L. Andersson, A. Farrel. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790 |
| Updated by: | RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7274 |
|
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special- purpose labels" in this document.
As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.
This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special- purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLSLabel Values" and creates a new registry called the "ExtendedSpecial-Purpose MPLS Label Values" registry.
This document updates a number of previous RFCs that use the term"reserved label". Specifically, this document updates RFCs 3032,3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and6790. |
|
| |
| RFC 7285 | Application-Layer Traffic Optimization (ALTO) Protocol |
| |
| Authors: | R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. |
| Date: | September 2014 |
| Formats: | txt html json |
| Updated by: | RFC 9274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7285 |
|
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
This document describes a protocol implementing the ALTO services.Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. |
|
| |
| RFC 7292 | PKCS #12: Personal Information Exchange Syntax v1.1 |
| |
| Authors: | K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9579 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7292 |
|
PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.
This document represents a republication of PKCS #12 v1.1 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. |
|
| |
| RFC 7296 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
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 document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. |
|
| |
| RFC 7299 | Object Identifier Registry for the PKIX Working Group |
| |
|
|
When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7301 | Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension |
| |
| Authors: | S. Friedl, A. Popov, A. Langley, E. Stephan. |
| Date: | July 2014 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7301 |
|
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. |
|
| |
| RFC 7307 | LDP Extensions for Multi-Topology |
| |
| Authors: | Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9658 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7307 |
|
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing withinMultiprotocol Label Switching (MPLS) Label Distribution Protocol(LDP) networks, new extensions are required.
This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. |
|
| |
| RFC 7315 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP |
| |
|
|
This document describes a set of private header (P-header) SessionInitiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. TheP-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455. |
|
| |
| RFC 7322 | RFC Style Guide |
| |
|
|
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.This document obsoletes RFC 2223, "Instructions to RFC Authors". |
|
| |
| RFC 7343 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) |
| |
|
|
This document specifies an updated Overlay Routable CryptographicHash Identifiers (ORCHID) format that obsoletes that in RFC 4843.These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators.They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. |
|
| |
| RFC 7344 | Automating DNSSEC Delegation Trust Maintenance |
| |
|
|
This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. |
|
| |
| RFC 7345 | UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) |
| |
| Authors: | C. Holmberg, I. Sedlacek, G. Salgueiro. |
| Date: | August 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7345 |
|
This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session DescriptionProtocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). |
|
| |
| RFC 7370 | Updates to the IS-IS TLV Codepoints Registry |
| |
|
|
This document recommends some editorial changes to the IANA "IS-ISTLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry. |
|
| |
| RFC 7385 | IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points |
| |
|
|
RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSITunnel) attribute". However, the RFC did not create a correspondingIANA registry.
There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose. |
|
| |
| RFC 7401 | Host Identity Protocol Version 2 (HIPv2) |
| |
|
|
This document specifies the details of the Host Identity Protocol(HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.
This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. |
|
| |
| RFC 7414 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. |
| Date: | February 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 4614 |
| Updated by: | RFC 7805 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7414 |
|
This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.
This document obsoletes RFC 4614. |
|
| |
| RFC 7432 | BGP MPLS-Based Ethernet VPN |
| |
| Authors: | A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. |
| Date: | February 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8584, RFC 9161, RFC 9572, RFC 9573 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7432 |
|
This document describes procedures for BGP MPLS-based Ethernet VPNs(EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". |
|
| |
| RFC 7437 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 7450 | Automatic Multicast Tunneling |
| |
|
|
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. |
|
| |
| RFC 7465 | Prohibiting RC4 Cipher Suites |
| |
|
|
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. |
|
| |
| RFC 7473 | Controlling State Advertisements of Non-negotiated LDP Applications |
| |
|
|
There is no capability negotiation done for Label DistributionProtocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session. |
|
| |
| RFC 7484 | Finding the Authoritative Registration Data (RDAP) Service |
| |
|
|
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers. |
|
| |
| RFC 7489 | Domain-based Message Authentication, Reporting, and Conformance (DMARC) |
| |
|
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.
Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits:Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.
DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. |
|
| |
| RFC 7519 | JSON Web Token (JWT) |
| |
|
|
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSONWeb Signature (JWS) structure or as the plaintext of a JSON WebEncryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted. |
|
| |
| RFC 7524 | Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) |
| |
| Authors: | Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. |
| Date: | May 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8534 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7524 |
|
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra- area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled usingP2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or(point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may beBGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. |
|
| |
| RFC 7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS.The recommendations are applicable to the majority of use cases. |
|
| |
| RFC 7530 | Network File System (NFS) Version 4 Protocol |
| |
|
|
The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol.In addition, support for strong security (and its negotiation),COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
This document, together with the companion External DataRepresentation (XDR) description document, RFC 7531, obsoletes RFC3530 as the definition of the NFS version 4 protocol. |
|
| |
| RFC 7540 | Hypertext Transfer Protocol Version 2 (HTTP/2) |
| |
|
|
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, theHTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. |
|
| |
| RFC 7551 | RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. |
| Date: | May 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8537 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7551 |
|
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label SwitchedPaths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. TheREVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. |
|
| |
| RFC 7562 | Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates |
| |
|
|
This document specifies the use of Digital Transmission ContentProtection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containingDTCP certificates issued by the Digital Transmission LicensingAdministrator (DTLA). |
|
| |
| RFC 7568 | Deprecating Secure Sockets Layer Version 3.0 |
| |
| Authors: | R. Barnes, M. Thomson, A. Pironti, A. Langley. |
| Date: | June 2015 |
| Formats: | txt json html |
| Updates: | RFC 5246 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7568 |
|
The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, TransportLayer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.
This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3. |
|
| |
| RFC 7582 | Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels |
| |
|
|
A set of prior RFCs specify procedures for supporting multicast inBGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. |
|
| |
| RFC 7595 | Guidelines and Registration Procedures for URI Schemes |
| |
|
|
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of UniformResource Identifier (URI) schemes. It obsoletes RFC 4395. |
|
| |
| RFC 7598 | DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients |
| |
| Authors: | T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. |
| Date: | July 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8539 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7598 |
|
This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices.Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. |
|
| |
| RFC 7631 | TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format |
| |
|
|
This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork(MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.
This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes toRFC 5444. |
|
| |
| RFC 7641 | Observing Resources in the Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to"observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. |
|
| |
| RFC 7677 | SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
| |
|
|
This document registers the Simple Authentication and Security Layer(SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802. |
|
| |
| RFC 7683 | Diameter Overload Indication Conveyance |
| |
| Authors: | J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. |
| Date: | October 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8581 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7683 |
|
This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance(DOIC). |
|
| |
| RFC 7752 | North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP |
| |
| Authors: | H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. |
| Date: | March 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9552 |
| Updated by: | RFC 9029 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7752 |
|
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs). |
|
| |
| RFC 7761 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.
This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM MulticastBorder Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. |
|
| |
| RFC 7766 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.This document obsoletes RFC 5966 and therefore updates RFC 1035 andRFC 1123. |
|
| |
| RFC 7776 | IETF Anti-Harassment Procedures |
| |
|
|
IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.
This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. |
|
| |
| RFC 7780 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
Since the publication of the TRILL (Transparent Interconnection ofLots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station AddressDistribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs6325, 7177, and 7179. |
|
| |
| RFC 7788 | Home Networking Control Protocol |
| |
| Authors: | M. Stenberg, S. Barth, P. Pfister. |
| Date: | April 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8375 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7788 |
|
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address. |
|
| |
| RFC 7841 | RFC Streams, Headers, and Boilerplates |
| |
| Authors: | J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 5741 |
| Updated by: | RFC 9280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7841 |
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats. |
|
| |
| RFC 7845 | Ogg Encapsulation for the Opus Audio Codec |
| |
|
|
This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. |
|
| |
| RFC 7854 | BGP Monitoring Protocol (BMP) |
| |
|
|
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.BMP is not suitable for use as a routing protocol. |
|
| |
| RFC 7858 | Specification for DNS over Transport Layer Security (TLS) |
| |
| Authors: | Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. |
| Date: | May 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8310 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7858 |
|
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.
This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. |
|
| |
| RFC 7862 | Network File System (NFS) Version 4 Minor Version 2 Protocol |
| |
|
|
This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O)Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. |
|
| |
| RFC 7873 | Domain Name System (DNS) Cookies |
| |
| Authors: | D. Eastlake 3rd, M. Andrews. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9018 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7873 |
|
DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNSCookies are tolerant of NAT, NAT-PT (Network Address Translation -Protocol Translation), and anycast and can be incrementally deployed.(Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally trackInternet users.) |
|
| |
| RFC 7900 | Extranet Multicast in BGP/IP MPLS VPNs |
| |
|
|
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN(Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. |
|
| |
| RFC 7935 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 7941 | RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items |
| |
|
|
Source Description (SDES) items are normally transported in the RTPControl Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. |
|
| |
| RFC 7950 | The YANG 1.1 Data Modeling Language |
| |
|
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 7959 | Block-Wise Transfers in the Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security(DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updatesRFC 7252. |
|
| |
| RFC 7983 | Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) |
| |
|
|
This document defines how Datagram Transport Layer Security (DTLS),Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTPExtension for DTLS"), which suffered from four issues described and fixed in this document.
This document updates RFC 5764. |
|
| |
| RFC 8008 | Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics |
| |
| Authors: | J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. |
| Date: | December 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9388 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8008 |
|
This document captures the semantics of the "Footprint andCapabilities Advertisement" part of the Content Delivery NetworkInterconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for theCDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. |
|
| |
| RFC 8018 | PKCS #5: Password-Based Cryptography Specification Version 2.1 |
| |
|
|
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.
This document represents a republication of PKCS #5 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 2898. |
|
| |
| RFC 8029 | Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures |
| |
| Authors: | K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. |
| Date: | March 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 4379, RFC 6424, RFC 6829, RFC 7537 |
| Updates: | RFC 1122 |
| Updated by: | RFC 8611, RFC 9041, RFC 9570 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8029 |
|
This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) LabelSwitched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.
This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updatesRFC 1122. |
|
| |
| RFC 8040 | RESTCONF Protocol |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | January 2017 |
| Formats: | txt json html |
| Updated by: | RFC 8527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8040 |
|
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 8060 | LISP Canonical Address Format (LCAF) |
| |
| Authors: | D. Farinacci, D. Meyer, J. Snijders. |
| Date: | February 2017 |
| Formats: | txt json html |
| Updated by: | RFC 9306 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8060 |
|
This document defines a canonical address format encoding used inLocator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. |
|
| |
| RFC 8078 | Managing DS Records from the Parent via CDS/CDNSKEY |
| |
|
|
RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevatesRFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. |
|
| |
| RFC 8085 | UDP Usage Guidelines |
| |
|
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ExplicitCongestion Notification (ECN), Differentiated Services Code Points(DSCPs), and ports.
Because congestion control is critical to the stable operation of theInternet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.
Some guidance is also applicable to the design of other protocols(e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.
This document obsoletes RFC 5405 and adds guidelines for multicastUDP usage. |
|
| |
| RFC 8122 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. |
|
| |
| RFC 8138 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header |
| |
|
|
This specification introduces a new IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of RoutingProtocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. |
|
| |
| RFC 8145 | Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) |
| |
| Authors: | D. Wessels, W. Kumari, P. Hoffman. |
| Date: | April 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8145 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in aDNSSEC-signed zone. |
|
| |
| RFC 8166 | Remote Direct Memory Access Transport for Remote Procedure Call Version 1 |
| |
|
|
This document specifies a protocol for conveying Remote ProcedureCall (RPC) messages on physical transports capable of Remote DirectMemory Access (RDMA). This protocol is referred to as the RPC-over-RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666. |
|
| |
| RFC 8182 | The RPKI Repository Delta Protocol (RRDP) |
| |
|
|
In the Resource Public Key Infrastructure (RPKI), CertificateAuthorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a newRPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an UpdateNotification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security(TLS)), and it enables the use of Content Distribution Networks(CDNs) or other caching infrastructures for the retrieval of these files. |
|
| |
| RFC 8198 | Aggressive Use of DNSSEC-Validated Cache |
| |
|
|
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certainDoS attacks in some circumstances.
This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. |
|
| |
| RFC 8200 | Internet Protocol, Version 6 (IPv6) Specification |
| |
|
|
This document specifies version 6 of the Internet Protocol (IPv6).It obsoletes RFC 2460. |
|
| |
| RFC 8205 | BGPsec Protocol Specification |
| |
| Authors: | M. Lepinski, Ed., K. Sriram, Ed.. |
| Date: | September 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8206 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8205 |
|
This document describes BGPsec, an extension to the Border GatewayProtocol (BGP) that provides security for the path of AutonomousSystems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates theUPDATE message. The digital signatures provide confidence that everyAS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. |
|
| |
| RFC 8221 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
| Authors: | P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. |
| Date: | October 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 7321 |
| Updated by: | RFC 9395 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8221 |
|
This document replaces RFC 7321, "Cryptographic AlgorithmImplementation Requirements and Usage Guidance for EncapsulatingSecurity Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. |
|
| |
| RFC 8224 | Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, C. Jennings, E. Rescorla, C. Wendt. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 4474 |
| Updated by: | RFC 8946 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8224 |
|
The baseline security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining aSIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
This document obsoletes RFC 4474. |
|
| |
| RFC 8226 | Secure Telephone Identity Credentials: Certificates |
| |
| Authors: | J. Peterson, S. Turner. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8226 |
|
In order to prevent the impersonation of telephone numbers on theInternet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. |
|
| |
| RFC 8231 | Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and acrossPCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. |
|
| |
| RFC 8247 | Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE) protocol is used to negotiate the IPsec SecurityAssociation (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updatesRFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsecEncapsulating Security Payload (ESP). |
|
| |
| RFC 8261 | Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets |
| |
|
|
The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocolsIPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, theSCTP associations carried over DTLS can only be single-homed. |
|
| |
| RFC 8280 | Research into Human Rights Protocol Considerations |
| |
|
|
This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.
This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights ProtocolConsiderations (HRPC) Research Group and also by individuals from outside the research group. |
|
| |
| RFC 8287 | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes |
| |
| Authors: | N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. |
| Date: | December 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8690, RFC 9214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8287 |
|
A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of aMultiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.
The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture.This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix andIGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane. |
|
| |
| RFC 8300 | Network Service Header (NSH) |
| |
| Authors: | P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. |
| Date: | January 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9451 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8300 |
|
This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining(SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). |
|
| |
| RFC 8306 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. |
| Date: | November 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 6006 |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8306 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE Communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
This document obsoletes RFC 6006. |
|
| |
| RFC 8308 | Extension Negotiation in the Secure Shell (SSH) Protocol |
| |
|
|
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially afterSSH key exchange. |
|
| |
| RFC 8314 | Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |
| |
|
|
This specification outlines current recommendations for the use ofTransport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501,5068, 6186, and 6409. |
|
| |
| RFC 8323 | CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets |
| |
| Authors: | C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. |
| Date: | February 2018 |
| Formats: | txt html json |
| Updates: | RFC 7641, RFC 7959 |
| Updated by: | RFC 8974 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8323 |
|
The Constrained Application Protocol (CoAP), although inspired byHTTP, was designed to use UDP instead of TCP. The message layer ofCoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS).This document outlines the changes required to use CoAP over TCP,TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. |
|
| |
| RFC 8325 | Mapping Diffserv to IEEE 802.11 |
| |
| Authors: | T. Szigeti, J. Henry, F. Baker. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 8622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8325 |
|
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. |
|
| |
| RFC 8340 | YANG Tree Diagrams |
| |
|
|
This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. |
|
| |
| RFC 8364 | PIM Flooding Mechanism (PFM) and Source Discovery (SD) |
| |
|
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses aRendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIMFlooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets. |
|
| |
| RFC 8373 | Negotiating Human Language in Real-Time Communications |
| |
|
|
Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages.This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).
This document describes the need as well as a solution that uses newSDP media attributes. |
|
| |
| RFC 8401 | Bit Index Explicit Replication (BIER) Support via IS-IS |
| |
| Authors: | L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang. |
| Date: | June 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8401 |
|
This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture. |
|
| |
| RFC 8402 | Segment Routing Architecture |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir. |
| Date: | July 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9256 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8402 |
|
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called"segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by theDestination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. |
|
| |
| RFC 8407 | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol(NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087. |
|
| |
| RFC 8408 | Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages |
| |
| Authors: | S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick. |
| Date: | July 2018 |
| Formats: | txt html json |
| Updated by: | RFC 8664 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8408 |
|
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, otherTE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol(PCEP) to allow support for different path setup methods over a givenPCEP session. |
|
| |
| RFC 8410 | Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure |
| |
| Authors: | S. Josefsson, J. Schaad. |
| Date: | August 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9295 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8410 |
|
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 andEd448. The key agreement algorithms covered are X25519 and X448.The encoding for public key, private key, and Edwards-curve DigitalSignature Algorithm (EdDSA) structures is provided. |
|
| |
| RFC 8422 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier |
| |
| Authors: | Y. Nir, S. Josefsson, M. Pegourie-Gonnard. |
| Date: | August 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 4492 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8422 |
|
This document describes key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral EllipticCurve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) andEdwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.
This document obsoletes RFC 4492. |
|
| |
| RFC 8428 | Sensor Measurement Lists (SenML) |
| |
| Authors: | C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann. |
| Date: | August 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9100 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8428 |
|
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists(SenML). Representations are defined in JavaScript Object Notation(JSON), Concise Binary Object Representation (CBOR), ExtensibleMarkup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. |
|
| |
| RFC 8444 | OSPFv2 Extensions for Bit Index Explicit Replication (BIER) |
| |
| Authors: | P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin. |
| Date: | November 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8444 |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). TheBFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in theBIER packet header.
This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document. |
|
| |
| RFC 8445 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based communication. This protocol is calledInteractive Connectivity Establishment (ICE). ICE makes use of theSession Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
This document obsoletes RFC 5245. |
|
| |
| RFC 8481 | Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) |
| |
|
|
Deployment of BGP origin validation based on Resource Public KeyInfrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration.This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration. |
|
| |
| RFC 8505 | Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery |
| |
|
|
This specification updates RFC 6775 -- the Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the RoutingRegistrars performing routing for host routes and/or proxy NeighborDiscovery in a low-power network. |
|
| |
| RFC 8572 | Secure Zero Touch Provisioning (SZTP) |
| |
| Authors: | K. Watsen, I. Farrer, M. Abrahamsson. |
| Date: | April 2019 |
| Formats: | txt json html |
| Updated by: | RFC 9646 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8572 |
|
This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. |
|
| |
| RFC 8609 | Content-Centric Networking (CCNx) Messages in TLV Format |
| |
| Authors: | M. Mosko, I. Solis, C. Wood. |
| Date: | July 2019 |
| Formats: | txt html json |
| Updated by: | RFC 9510 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8609 |
|
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in aTLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review amongICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. |
|
| |
| RFC 8610 | Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures |
| |
| Authors: | H. Birkholz, C. Vigano, C. Bormann. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updated by: | RFC 9682 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8610 |
|
This document proposes a notational convention to express ConciseBinary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR orJSON. |
|
| |
| RFC 8611 | Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces |
| |
| Authors: | N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updates: | RFC 8029 |
| Updated by: | RFC 9041 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8611 |
|
This document defines extensions to the MPLS Label Switched Path(LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-CostMultipath (ECMP) over Link Aggregation Group (LAG) interfaces.Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
This document updates RFC 8029. |
|
| |
| RFC 8620 | The JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. |
|
| |
| RFC 8624 | Algorithm Implementation Requirements and Usage Guidance for DNSSEC |
| |
|
|
The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers andDNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletesRFC 6944. |
|
| |
| RFC 8713 | IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC(IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF AdministrativeSupport Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.
This document obsoletes RFC 7437 and RFC 8318. |
|
| |
| RFC 8724 | SCHC: Generic Framework for Static Context Header Compression and Fragmentation |
| |
| Authors: | A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga. |
| Date: | April 2020 |
| Formats: | txt json xml html pdf |
| Updated by: | RFC 9441 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8724 |
|
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.
This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.
The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.This document standardizes the exchange over the LPWAN between twoSCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. |
|
| |
| RFC 8729 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. This document obsoletesRFC 4844. |
|
| |
| RFC 8730 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrationLimited Liability Company (LLC).
This version obsoletes RFC 6548 to replace all references to theInternet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure. |
|
| |
| RFC 8762 | Simple Two-Way Active Measurement Protocol |
| |
|
|
This document describes the Simple Two-way Active MeasurementProtocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. |
|
| |
| RFC 8794 | Extensible Binary Meta Language |
| |
|
|
This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage.EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines howEBML Schemas are created to convey the semantics of an EBML Document. |
|
| |
| RFC 8838 | Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol |
| |
|
|
This document describes "Trickle ICE", an extension to theInteractive Connectivity Establishment (ICE) protocol that enablesICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session. |
|
| |
| RFC 8878 | Zstandard Compression and the 'application/zstd' Media Type |
| |
|
|
Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.
Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.
This document replaces and obsoletes RFC 8478. |
|
| |
| RFC 8955 | Dissemination of Flow Specification Rules |
| |
|
|
This document defines a Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic FlowSpecifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the FlowSpecification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.
This document obsoletes both RFC 5575 and RFC 7674. |
|
| |
| RFC 8967 | MAC Authentication for the Babel Routing Protocol |
| |
|
|
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance.This document obsoletes RFC 7298. |
|
| |
| RFC 8999 | Version-Independent Properties of QUIC |
| |
|
|
This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. |
|
| |
| RFC 9010 | Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves |
| |
|
|
This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. |
|
| |
| RFC 9052 | CBOR Object Signing and Encryption (COSE): Structures and Process |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152. |
|
| |
| RFC 9085 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing |
| |
| Authors: | S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen. |
| Date: | August 2021 |
| Formats: | txt xml json pdf html |
| Updated by: | RFC 9356 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9085 |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called"segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.
This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) address family in order to carry SR information via BGP. |
|
| |
| RFC 9127 | YANG Data Model for Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky. |
| Date: | October 2021 |
| Formats: | txt html pdf xml json |
| Updated by: | RFC 9314 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9127 |
|
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342). |
|
| |
| RFC 9202 | Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| Authors: | S. Gerdes, O. Bergmann, C. Bormann, G. Selander, L. Seitz. |
| Date: | August 2022 |
| Formats: | txt json pdf xml html |
| Updated by: | RFC 9430 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9202 |
|
This specification defines a profile of the Authentication andAuthorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. |
|
| |
| RFC 9298 | Proxying UDP in HTTP |
| |
|
|
This document describes how to proxy UDP in HTTP, similar to how theHTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. |
|
| |
| RFC 9363 | A YANG Data Model for Static Context Header Compression (SCHC) |
| |
|
|
This document describes a YANG data model for the Static ContextHeader Compression (SCHC) compression and fragmentation Rules.
This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set ofRules or to modify the parameters of some Rules. |
|
