| |
| 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 |
| |
| Authors: | J. Postel, S.D. Crocker. |
| Date: | July 1970 |
| Formats: | txt pdf |
| Updated by: | RFC 0069 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 54 | Official Protocol Proffering |
| |
| Authors: | S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. |
| Date: | June 1970 |
| Formats: | txt pdf |
| Updated by: | RFC 0057 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 66 | NIC - third level ideas and other noise |
| |
|
| |
| RFC 70 | Note on Padding |
| |
| Authors: | S.D. Crocker. |
| Date: | October 1970 |
| Formats: | txt pdf |
| Updated by: | RFC 0228 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 |
| |
| Authors: | S.D. Crocker. |
| Date: | January 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0125 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 98 | Logger Protocol Proposal |
| |
| Authors: | E. Meyer, T. Skinner. |
| Date: | February 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0123 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 99 | Network Meeting |
| |
| Authors: | P.M. Karp. |
| Date: | February 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0116 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 |
| |
| Authors: | S.D. Crocker. |
| Date: | February 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0107 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 105 | Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB |
| |
| Authors: | J.E. White. |
| Date: | March 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0217 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 |
| |
| Authors: | J. Winett. |
| Date: | March 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0135 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Updated by: | RFC 0227 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Updated by: | RFC 0147 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 137 | Telnet Protocol - a proposed document |
| |
| Authors: | T.C. O'Sullivan. |
| Date: | April 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0139 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 139 | Discussion of Telnet Protocol |
| |
|
| |
| RFC 140 | Agenda for the May NWG meeting |
| |
| Authors: | S.D. Crocker. |
| Date: | May 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0149 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Obsoleted by: | RFC 0264 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Obsoleted by: | RFC 0265 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 177 | Device independent graphical display description |
| |
|
| |
| RFC 189 | Interim NETRJS specifications |
| |
|
| |
| RFC 193 | NETWORK CHECKOUT |
| |
| Authors: | E. Harslem, J.F. Heafner. |
| Date: | July 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0198 |
| Updated by: | RFC 0198 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 204 | Sockets in use |
| |
| Authors: | J. Postel. |
| Date: | August 1971 |
| Formats: | txt pdf |
| Updated by: | RFC 0234 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 212 | NWG meeting on network usage |
| |
| Authors: | Information Sciences Institute University of Southern California. |
| Date: | August 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0207 |
| Updated by: | RFC 0222 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 222 | Subject: System programmer's workshop |
| |
| Authors: | R.M. Metcalfe. |
| Date: | September 1971 |
| Formats: | txt pdf |
| Updates: | RFC 0212 |
| Updated by: | RFC 0234 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Obsoletes: | RFC 0171 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0310 |
| Also: | RFC 0265 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 pdf |
| Obsoletes: | RFC 0172 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0281, RFC 0294, RFC 0310 |
| Also: | RFC 0264 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 288 | Network host status |
| |
|
| |
| RFC 318 | Telnet Protocols |
| |
|
| |
| RFC 319 | Network Host Status |
| |
|
| |
| RFC 323 | Formation of Network Measurement Group (NMG) |
| |
| Authors: | V. Cerf. |
| Date: | March 1972 |
| Formats: | txt pdf |
| Updated by: | RFC 0388 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 330 | Network Host Status |
| |
|
| |
| RFC 354 | File Transfer Protocol |
| |
|
| |
| RFC 370 | Network Host Status |
| |
|
| |
| RFC 381 | Three aids to improved network operation |
| |
| Authors: | J.M. McQuillan. |
| Date: | July 1972 |
| Formats: | txt pdf |
| Updated by: | RFC 0394 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 385 | Comments on the File Transfer Protocol |
| |
|
| |
| RFC 387 | Some experiences in implementing Network Graphics Protocol Level 0 |
| |
| Authors: | K.C. Kelley, J. Meir. |
| Date: | August 1972 |
| Formats: | txt pdf |
| Updated by: | RFC 0401 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 396 | Network Graphics Working Group Meeting - Second Iteration |
| |
| Authors: | S. Bunch. |
| Date: | November 1972 |
| Formats: | txt pdf |
| Updated by: | RFC 0474 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 404 | Host Address Changes Involving Rand and ISI |
| |
| Authors: | A.M. McKenzie. |
| Date: | October 1972 |
| Formats: | txt pdf |
| Updated by: | RFC 0405 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 442 | Current flow-control scheme for IMPSYS |
| |
| Authors: | V. Cerf. |
| Date: | January 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0449 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 467 | Proposed change to Host-Host Protocol: Resynchronization of connection status |
| |
| Authors: | J.D. Burchfiel, R.S. Tomlinson. |
| Date: | February 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0492 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 482 | Traffic statistics (February 1973) |
| |
| Authors: | A.M. McKenzie. |
| Date: | March 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0497 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 495 | Telnet Protocol specifications |
| |
|
| |
| RFC 538 | Traffic statistics (June 1973) |
| |
| Authors: | A.M. McKenzie. |
| Date: | July 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0556 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 542 | File Transfer Protocol |
| |
|
| |
| RFC 560 | Remote Controlled Transmission and Echoing Telnet option |
| |
| Authors: | D. Crocker, J. Postel. |
| Date: | August 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0581 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 561 | Standardizing Network Mail Headers |
| |
| Authors: | A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. |
| Date: | September 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0680 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 566 | Traffic statistics (August 1973) |
| |
| Authors: | A.M. McKenzie. |
| Date: | September 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0579 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 567 | Cross Country Network Bandwidth |
| |
| Authors: | L.P. Deutsch. |
| Date: | September 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0568 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 579 | Traffic statistics (September 1973) |
| |
|
| |
| RFC 580 | Note to Protocol Designers and Implementers |
| |
| Authors: | J. Postel. |
| Date: | October 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0582 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 597 | Host status |
| |
| Authors: | N. Neigus, E.J. Feinler. |
| Date: | December 1973 |
| Formats: | txt pdf |
| Updated by: | RFC 0603 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 603 | Response to RFC 597: Host status |
| |
| Authors: | J.D. Burchfiel. |
| Date: | December 1973 |
| Formats: | txt pdf |
| Updates: | RFC 0597 |
| Updated by: | RFC 0613 |
| Status: | UNKNOWN |
|
Questions about the ARPANET topology described in RFC 597. |
|
| |
| RFC 607 | Comments on the File Transfer Protocol |
| |
| Authors: | M. Krilanovich, G. Gregg. |
| Date: | January 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0624 |
| Updated by: | RFC 0614 |
| Status: | UNKNOWN |
|
An old version; see RFC 624; see also RFCs 614, 542 and 640. |
|
| |
| RFC 661 | Protocol information |
| |
| Authors: | J. Postel. |
| Date: | November 1974 |
| Formats: | txt pdf |
| Updated by: | RFC 0694 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 |
| |
| Authors: | D.W. Dodds. |
| Date: | August 1974 |
| Formats: | txt pdf |
| Updated by: | RFC 0702 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 702 | September, 1974, survey of New-Protocol Telnet servers |
| |
|
| |
| RFC 732 | Telnet Data Entry Terminal option |
| |
|
| |
| RFC 760 | DoD standard Internet Protocol |
| |
| Authors: | J. Postel. |
| Date: | January 1980 |
| Formats: | txt pdf |
| Obsoletes: | IEN 123 |
| Obsoleted by: | RFC 0791 |
| Updated by: | RFC 0777 |
| Status: | UNKNOWN |
|
|
|
| |
| 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 | 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) |
| |
| Authors: | E.C. Rosen. |
| Date: | October 1982 |
| Formats: | txt pdf |
| Updated by: | RFC 0904 |
| Status: | UNKNOWN |
|
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 881 | Domain names plan and schedule |
| |
| Authors: | J. Postel. |
| Date: | November 1983 |
| Formats: | txt pdf |
| Updated by: | RFC 0897 |
| Status: | UNKNOWN |
|
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 |
| |
| Authors: | L. Seamonson, E.C. Rosen. |
| Date: | January 1984 |
| Formats: | txt pdf |
| Updated by: | RFC 0904 |
| Status: | UNKNOWN |
|
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 |
| |
| Authors: | Bolt Beranek and Newman Laboratories. |
| Date: | July 1984 |
| Formats: | txt pdf |
| Updated by: | RFC 1221 |
| Also: | STD 0040 |
| Status: | STANDARD |
|
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 pdf |
| Updated by: | RFC 1151 |
| Status: | EXPERIMENTAL |
|
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 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 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 |
| |
| Authors: | M.R. Horton. |
| Date: | February 1986 |
| Formats: | txt pdf |
| Updated by: | RFC 1137 |
| Status: | UNKNOWN |
|
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 |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | May 1987 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0991 |
| Updated by: | RFC 6093 |
| Status: | UNKNOWN |
|
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.V. Mockapetris. |
| Date: | November 1987 |
| Formats: | txt pdf |
| 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 |
| Also: | STD 0013 |
| Status: | STANDARD |
|
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.V. Mockapetris. |
| Date: | November 1987 |
| Formats: | txt pdf |
| 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 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604 |
| Also: | STD 0013 |
| Status: | STANDARD |
|
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 |
| |
| Authors: | Y. Rekhter. |
| Date: | January 1988 |
| Formats: | txt pdf |
| Updated by: | RFC 6270 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | K. Hardwick, J. Lekashman. |
| Date: | February 1988 |
| Formats: | txt pdf |
| Updated by: | RFC 5494 |
| Also: | STD 0045 |
| Status: | STANDARD |
|
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 pdf |
| Updated by: | RFC 1141 |
| Status: | UNKNOWN |
|
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 |
| |
| Authors: | T. Mallory, A. Kullberg. |
| Date: | January 1990 |
| Formats: | txt pdf |
| Updates: | RFC 1071 |
| Updated by: | RFC 1624 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | D. Waitzman. |
| Date: | April 1 1990 |
| Formats: | txt pdf |
| Updated by: | RFC 2549 |
| Status: | EXPERIMENTAL |
|
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 |
| |
| Authors: | P. Chmielewski. |
| Date: | February 1991 |
| Formats: | txt pdf |
| Updated by: | RFC 2877 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | K. McCloghrie. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1573 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | K. McCloghrie, R. Fox. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Updated by: | RFC 1239 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | F. Baker, C.P. Kolb. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1406 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
|
|
| |
| RFC 1233 | Definitions of managed objects for the DS3 Interface type |
| |
| Authors: | T.A. Cox, K. Tesink. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1407 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Bradner. |
| Date: | July 1991 |
| Formats: | txt pdf |
| Updated by: | RFC 6201 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | F. Baker, R. Coltun. |
| Date: | July 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1252 |
| Updated by: | RFC 1349 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Waldbusser. |
| Date: | November 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1757 |
| Updated by: | RFC 1513 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Case. |
| Date: | January 1992 |
| Formats: | txt pdf |
| Updated by: | RFC 1512 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | R. Rivest. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Updated by: | RFC 6151 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | P. Kuehn. |
| Date: | May 1992 |
| Formats: | txt pdf |
| Updated by: | RFC 5494 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | G. McGregor. |
| Date: | May 1992 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1172 |
| Updated by: | RFC 3241 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | R. Braden. |
| Date: | November 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6247 |
| Updated by: | RFC 1644 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | D. Borman, Ed.. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Updated by: | RFC 1571 |
| Status: | HISTORIC |
|
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 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 |
| |
| Authors: | W. Simpson, Ed.. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Updates: | RFC 1548 |
| Updated by: | RFC 2484 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | E. Huizer, D. Crocker. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2418 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
|
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 1715 | The H Ratio for Address Assignment Efficiency |
| |
| Authors: | C. Huitema. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Updated by: | RFC 3194 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | T. Howes, S. Kille, W. Yeong, C. Robbins. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1488 |
| Obsoleted by: | RFC 3494 |
| Updated by: | RFC 2559 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | J. Moy. |
| Date: | April 1995 |
| Formats: | txt pdf |
| Updated by: | RFC 3883 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | R. Srinivasan. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Updated by: | RFC 5665 |
| Status: | PROPOSED STANDARD |
|
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] |
|
| |
| RFC 1858 | Security Considerations for IP Fragment Filtering |
| |
| Authors: | G. Ziemba, D. Reed, P. Traina. |
| Date: | October 1995 |
| Formats: | txt pdf |
| Updated by: | RFC 3128 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Obsoleted by: | RFC 4048 |
| Updated by: | RFC 4548 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | K. Moore, G. Vaudreuil. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3464 |
| Updated by: | RFC 2852 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | B. Carpenter, Ed.. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Updated by: | RFC 3439 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | D. Rand. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Updated by: | RFC 2153 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Linn. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Updated by: | RFC 4121 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | T. Bates, R. Chandra. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4456 |
| Updated by: | RFC 2796 |
| Status: | EXPERIMENTAL |
|
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 pdf |
| Updated by: | RFC 2297 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | W. Simpson. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1334 |
| Updated by: | RFC 2484 |
| Status: | DRAFT STANDARD |
|
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 2002 | IP Mobility Support |
| |
| Authors: | C. Perkins, Ed.. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3220 |
| Updated by: | RFC 2290 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | C. Perkins. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Updated by: | RFC 3168 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | M. Elkins. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Updated by: | RFC 3156 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
|
|
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 |
| |
| Authors: | H. Berkowitz. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 4192 |
| Status: | INFORMATIONAL |
|
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 2088 | IMAP4 non-synchronizing literals |
| |
| Authors: | J. Myers. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 4466 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6151 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 6055 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | C. Allocchio. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1664 |
| Updated by: | RFC 3597 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Veizades, E. Guttman, C. Perkins, S. Kaplan. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 2608, RFC 2609 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 5494 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | R. Troost, S. Dorner, K. Moore, Ed.. |
| Date: | August 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1806 |
| Updated by: | RFC 2184, RFC 2231 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6354 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5403 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
|
|
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 2244 | ACAP -- Application Configuration Access Protocol |
| |
| Authors: | C. Newman, J. G. Myers. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 6075 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4519, RFC 4524 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | K. Sollins. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Updated by: | RFC 3401 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | L. Blunk, J. Vollbrecht. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3748 |
| Updated by: | RFC 2484 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Solomon, S. Glass. |
| Date: | February 1998 |
| Formats: | txt pdf |
| Updates: | RFC 2002 |
| Updated by: | RFC 2794 |
| Status: | PROPOSED STANDARD |
|
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 2327 | SDP: Session Description Protocol |
| |
| Authors: | M. Handley, V. Jacobson. |
| Date: | April 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4566 |
| Updated by: | RFC 3266 |
| Status: | PROPOSED STANDARD |
|
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 2342 | IMAP4 Namespace |
| |
| Authors: | M. Gahrns, C. Newman. |
| Date: | May 1998 |
| Formats: | txt pdf |
| Updated by: | RFC 4466 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4519 |
| Status: | INFORMATIONAL |
|
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 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 |
| |
| Authors: | S. Kent, R. Atkinson. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1825 |
| Obsoleted by: | RFC 4301 |
| Updated by: | RFC 3168 |
| Status: | PROPOSED STANDARD |
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
| Authors: | D. Harkins, D. Carrel. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4306 |
| Updated by: | RFC 4109 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | T. Narten, H. Alvestrand. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5226 |
| Updated by: | RFC 3692 |
| Status: | BEST CURRENT PRACTICE |
|
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 |
| |
| Authors: | R. Gellens, C. Newman, L. Lundblade. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Updates: | RFC 1939 |
| Updated by: | RFC 5034 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1970 |
| Obsoleted by: | RFC 4861 |
| Updated by: | RFC 4311 |
| Status: | DRAFT STANDARD |
|
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 |
| |
| Authors: | M. Crawford. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1972 |
| Updated by: | RFC 6085 |
| Status: | PROPOSED STANDARD |
|
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 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 Service |
| |
| Authors: | S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Updated by: | RFC 3260 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| 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 |
|
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 2544 | Benchmarking Methodology for Network Interconnect Devices |
| |
| Authors: | S. Bradner, J. McQuaid. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1944 |
| Updated by: | RFC 6201 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2133 |
| Obsoleted by: | RFC 3493 |
| Updated by: | RFC 3152 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 6277 |
| Status: | PROPOSED STANDARD |
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK] |
|
| |
| RFC 2581 | TCP Congestion Control |
| |
| Authors: | M. Allman, V. Paxson, W. Stevens. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2001 |
| Obsoleted by: | RFC 5681 |
| Updated by: | RFC 3390 |
| Status: | PROPOSED STANDARD |
|
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 2595 | Using TLS with IMAP, POP3 and ACAP |
| |
| Authors: | C. Newman. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 4616 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3260 |
| Status: | PROPOSED STANDARD |
|
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 2608 | Service Location Protocol, Version 2 |
| |
| Authors: | E. Guttman, C. Perkins, J. Veizades, M. Day. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updates: | RFC 2165 |
| Updated by: | RFC 3224 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
|
|
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 pdf |
| Obsoletes: | RFC 2280 |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | P. Hoffman, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 5035 |
| Status: | PROPOSED STANDARD |
|
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] |
|
| |
| 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 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 pdf |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | S. Deering, W. Fenner, B. Haberman. |
| Date: | October 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 3590, RFC 3810 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6398 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
|
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 2739 | Calendar Attributes for vCard and LDAP |
| |
| Authors: | T. Small, D. Hennessy, F. Dawson. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Linn. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2078 |
| Updated by: | RFC 5554 |
| Status: | PROPOSED STANDARD |
|
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 2747 | RSVP Cryptographic Authentication |
| |
| Authors: | F. Baker, B. Lindell, M. Talwar. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 3097 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4261 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | G. Tsirtsis, P. Srisuresh. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4966 |
| Updated by: | RFC 3152 |
| Status: | HISTORIC |
|
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 |
| |
| Authors: | R. Rockell, R. Fink. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2546 |
| Updated by: | RFC 3152 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | A. Gulbrandsen, P. Vixie, L. Esibov. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2052 |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. |
| Date: | March 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 2890 |
| Status: | PROPOSED STANDARD |
|
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 2818 | HTTP Over TLS |
| |
| Authors: | E. Rescorla. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 5785 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4513, RFC 4510 |
| Updated by: | RFC 3377 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3632 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | J.-M. Pittet. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1374 |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | J.-M. Pittet. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Updates: | RFC 1035 |
| Updated by: | RFC 3645, RFC 4635 |
| Status: | PROPOSED STANDARD |
|
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 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 2869 | RADIUS Extensions |
| |
| Authors: | C. Rigney, W. Willats, P. Calhoun. |
| Date: | June 2000 |
| Formats: | txt pdf |
| Updated by: | RFC 3579, RFC 5080 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | A. Bierman, C. Bucci, R. Iddon. |
| Date: | August 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2074 |
| Updated by: | RFC 3395 |
| Status: | DRAFT STANDARD |
|
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 |
| |
|
|
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 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 pdf |
| Obsoleted by: | RFC 4960 |
| Updated by: | RFC 3309 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5063 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | M. Nystrom, B. Kaliski. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2314 |
| Updated by: | RFC 5967 |
| Status: | INFORMATIONAL |
|
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 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 3031 | Multiprotocol Label Switching Architecture |
| |
| Authors: | E. Rosen, A. Viswanathan, R. Callon. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Updated by: | RFC 6178 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586 |
| Status: | PROPOSED STANDARD |
|
"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 3046 | DHCP Relay Agent Information Option |
| |
| Authors: | M. Patrick. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Updated by: | RFC 6607 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3460 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 3759, RFC 4815 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | D. Eastlake 3rd, T. Goldstein. |
| Date: | April 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2706 |
| Updated by: | RFC 4112 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 5816 |
| Status: | PROPOSED STANDARD |
|
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 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 3174 | US Secure Hash Algorithm 1 (SHA1) |
| |
| Authors: | D. Eastlake 3rd, P. Jones. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Updated by: | RFC 4634, RFC 6234 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Updated by: | RFC 5350 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 3459, RFC 5621 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3468 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | C. Bormann. |
| Date: | April 2002 |
| Formats: | txt pdf |
| Updates: | RFC 1332 |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| 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 |
| Status: | PROPOSED STANDARD |
|
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 3264 | An Offer/Answer Model with Session Description Protocol (SDP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | June 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2543 |
| Updated by: | RFC 6157 |
| Status: | PROPOSED STANDARD |
|
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, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. |
| Date: | May 2002 |
| Formats: | txt pdf |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | S. Waldbusser. |
| Date: | July 2002 |
| Formats: | txt pdf |
| Updated by: | RFC 4502 |
| Status: | PROPOSED STANDARD |
|
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 3306 | Unicast-Prefix-based IPv6 Multicast Addresses |
| |
| Authors: | B. Haberman, D. Thaler. |
| Date: | August 2002 |
| Formats: | txt pdf |
| Updated by: | RFC 3956, RFC 4489 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. |
| Date: | October 2002 |
| Formats: | txt pdf ps |
| Updated by: | RFC 4032, RFC 5027 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
|
|
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 pdf |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | C. Jennings, J. Peterson, M. Watson. |
| Date: | November 2002 |
| Formats: | txt pdf |
| Updated by: | RFC 5876 |
| Status: | INFORMATIONAL |
|
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 3327 | Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts |
| |
| Authors: | D. Willis, B. Hoeneisen. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Updated by: | RFC 5626 |
| Status: | PROPOSED STANDARD |
|
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 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 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 pdf |
| Obsoletes: | RFC 2236 |
| Updated by: | RFC 4604 |
| Status: | PROPOSED STANDARD |
|
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 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) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2572 |
| Updated by: | RFC 5590 |
| Also: | STD 0062 |
| Status: | STANDARD |
|
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) |
| |
| Authors: | A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5727 |
| Updated by: | RFC 3968, RFC 3969 |
| Status: | BEST CURRENT PRACTICE |
|
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 3435 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | F. Andreasen, B. Foster. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2705 |
| Updated by: | RFC 3661 |
| Status: | INFORMATIONAL |
|
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 3443 | Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks |
| |
| Authors: | P. Agarwal, B. Akyol. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 3938 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | E. Burger. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Updates: | RFC 3204 |
| Updated by: | RFC 5621 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
|
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 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 |
| |
| Authors: | P. Ashwood-Smith, Ed., L. Berger, Ed.. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 3468, RFC 4201 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| 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 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | O. Aboul-Magd. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 3468 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | B. Rajagopalan. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 3468 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Updated by: | RFC 6107 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | G. Camarillo. |
| Date: | February 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 5049 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | A. Costello. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 5891 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
|
|
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 3516 | IMAP4 Binary Content Extension |
| |
| Authors: | L. Nerenberg. |
| Date: | April 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 4466 |
| Status: | PROPOSED STANDARD |
|
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 3550 | RTP: A Transport Protocol for Real-Time Applications |
| |
|
|
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 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) |
| |
| Authors: | A. Li. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 4788 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | A. Zinin. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 6233 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | F. Le Faucheur, W. Lai. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
|
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 3579 | RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) |
| |
| Authors: | B. Aboba, P. Calhoun. |
| Date: | September 2003 |
| Formats: | txt pdf |
| Updates: | RFC 2869 |
| Updated by: | RFC 5080 |
| Status: | INFORMATIONAL |
|
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 3588 | Diameter Base Protocol |
| |
| Authors: | P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. |
| Date: | September 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 5729, RFC 5719, RFC 6408 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5630 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | O. Troan, R. Droms. |
| Date: | December 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 6603 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5691 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Legg. |
| Date: | October 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 4792 |
| Status: | PROPOSED STANDARD |
|
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 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 3680 | A Session Initiation Protocol (SIP) Event Package for Registrations |
| |
| Authors: | J. Rosenberg. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6140 |
| Status: | PROPOSED STANDARD |
|
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 3693 | Geopriv Requirements |
| |
| Authors: | J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6280 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Updated by: | RFC 6280 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | K. Zeilenga, Ed.. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Updates: | RFC 2798 |
| Updated by: | RFC 4517 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4104 |
| Status: | PROPOSED STANDARD |
|
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 3709 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
| Authors: | S. Santesson, R. Housley, T. Freeman. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6170 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 5506 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. |
| Date: | April 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 3980, RFC 4850, RFC 5048 |
| Status: | PROPOSED STANDARD |
|
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 3748 | Extensible Authentication Protocol (EAP) |
| |
| Authors: | B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed.. |
| Date: | June 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2284 |
| Updated by: | RFC 5247 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | O. Levin. |
| Date: | April 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Peterson. |
| Date: | April 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 4877 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | H. Smit, T. Li. |
| Date: | June 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5305 |
| Updated by: | RFC 4205 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | R. Vida, Ed., L. Costa, Ed.. |
| Date: | June 2004 |
| Formats: | txt pdf |
| Updates: | RFC 2710 |
| Updated by: | RFC 4604 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4738, RFC 6309 |
| Status: | PROPOSED STANDARD |
|
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 3834 | Recommendations for Automatic Responses to Electronic Mail |
| |
| Authors: | K. Moore. |
| Date: | August 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 5436 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
|
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 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 3920 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
| Authors: | P. Saint-Andre, Ed.. |
| Date: | October 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6120 |
| Updated by: | RFC 6122 |
| Status: | PROPOSED STANDARD |
|
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 3931 | Layer Two Tunneling Protocol - Version 3 (L2TPv3) |
| |
| Authors: | J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.. |
| Date: | March 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
|
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 3945 | Generalized Multi-Protocol Label Switching (GMPLS) Architecture |
| |
| Authors: | E. Mannie, Ed.. |
| Date: | October 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 6002 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Peterson. |
| Date: | January 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning presURIs in ENUM. |
|
| |
| RFC 3966 | The tel URI for Telephone Numbers |
| |
| Authors: | H. Schulzrinne. |
| Date: | December 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2806 |
| Updated by: | RFC 5341 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | R. Bush, T. Narten. |
| Date: | December 2004 |
| Formats: | txt pdf |
| Updated by: | RFC 4897 |
| Also: | BCP 0097 |
| Status: | BEST CURRENT PRACTICE |
|
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 3971 | SEcure Neighbor Discovery (SEND) |
| |
| Authors: | J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander. |
| Date: | March 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6494, RFC 6495 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | A. Newton, M. Sanz. |
| Date: | January 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 4992 |
| Status: | PROPOSED STANDARD |
|
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 3985 | Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture |
| |
| Authors: | S. Bryant, Ed., P. Pate, Ed.. |
| Date: | March 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
|
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 4002 | IANA Registration for Enumservice 'web' and 'ft' |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 4019 | RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite |
| |
| Authors: | G. Pelletier. |
| Date: | April 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | G. Klyne, J. Palme. |
| Date: | March 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5322 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5332 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| 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 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| 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 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| 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 |
| Status: | PROPOSED STANDARD |
|
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 4048 | RFC 1888 Is Obsolete |
| |
| Authors: | B. Carpenter. |
| Date: | April 2005 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1888 |
| Updated by: | RFC 4548 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | J. Schaad, B. Kaliski, R. Housley. |
| Date: | June 2005 |
| Formats: | txt pdf |
| Updates: | RFC 3279 |
| Updated by: | RFC 5756 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | R. Austein, Ed., B. Wijnen, Ed.. |
| Date: | April 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 4371 |
| Also: | BCP 0101 |
| Status: | BEST CURRENT PRACTICE |
|
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 4102 | Registration of the text/red MIME Sub-Type |
| |
| Authors: | P. Jones. |
| Date: | June 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6354 |
| Status: | PROPOSED STANDARD |
|
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 4119 | A Presence-based GEOPRIV Location Object Format |
| |
| Authors: | J. Peterson. |
| Date: | December 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5139, RFC 5491 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
|
|
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 4138 | Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | P. Sarolahti, M. Kojo. |
| Date: | August 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5682 |
| Status: | EXPERIMENTAL |
|
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 pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 4572 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6172 |
| Status: | PROPOSED STANDARD |
|
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 4175 | RTP Payload Format for Uncompressed Video |
| |
| Authors: | L. Gharai, C. Perkins. |
| Date: | September 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 4421 |
| Status: | PROPOSED STANDARD |
|
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 4181 | Guidelines for Authors and Reviewers of MIB Documents |
| |
| Authors: | C. Heard, Ed.. |
| Date: | September 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 4841 |
| Also: | BCP 0111 |
| Status: | BEST CURRENT PRACTICE |
|
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. |
|
| |
| RFC 4182 | Removing a Restriction on the use of MPLS Explicit NULL |
| |
| Authors: | E. Rosen. |
| Date: | September 2005 |
| Formats: | txt pdf |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | J. Arkko, H. Haverinen. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5448 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | K. Kompella, Ed., Y. Rekhter, Ed.. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6001, RFC 6002 |
| Status: | PROPOSED STANDARD |
|
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 4206 | Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) |
| |
| Authors: | K. Kompella, Y. Rekhter. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6001, RFC 6107 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Obsoletes: | RFC 3057 |
| Updated by: | RFC 5133 |
| Status: | PROPOSED STANDARD |
|
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 4238 | Voice Message Routing Service |
| |
| Authors: | G. Vaudreuil. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 4271 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1771 |
| Updated by: | RFC 6286, RFC 6608 |
| Status: | DRAFT STANDARD |
|
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 4287 | The Atom Syndication Format |
| |
| Authors: | M. Nottingham, Ed., R. Sayre, Ed.. |
| Date: | December 2005 |
| Formats: | txt pdf |
| Updated by: | RFC 5988 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Loughney, Ed.. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6434 |
| Updated by: | RFC 5095 |
| Status: | INFORMATIONAL |
|
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 4337 | MIME Type Registration for MPEG-4 |
| |
| Authors: | Y Lim, D. Singer. |
| Date: | March 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
|
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 4342 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) |
| |
| Authors: | S. Floyd, E. Kohler, J. Padhye. |
| Date: | March 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5348, RFC 6323 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | E. Rescorla, N. Modadugu. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6347 |
| Updated by: | RFC 5746 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Ahmadi. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 4424 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | L-E. Jonsson, G. Pelletier, K. Sandlund. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3242 |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
|
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 4388 | Dynamic Host Configuration Protocol (DHCP) Leasequery |
| |
| Authors: | R. Woundy, K. Kinnear. |
| Date: | February 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6148 |
| Status: | PROPOSED STANDARD |
|
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 4393 | MIME Type Registrations for 3GPP2 Multimedia Files |
| |
| Authors: | H. Garudadri. |
| Date: | March 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
|
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 4415 | IANA Registration for Enumservice Voice |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 4443 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
| Authors: | A. Conta, S. Deering, M. Gupta, Ed.. |
| Date: | March 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2463 |
| Updates: | RFC 2780 |
| Updated by: | RFC 4884 |
| Status: | DRAFT STANDARD |
|
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 4448 | Encapsulation Methods for Transport of Ethernet over MPLS Networks |
| |
| Authors: | L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
| Authors: | C. Newman. |
| Date: | May 2006 |
| Formats: | txt pdf |
| Updates: | RFC 3463 |
| Updated by: | RFC 5248 |
| Status: | PROPOSED STANDARD |
|
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 4492 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. |
| Date: | May 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5246 |
| Status: | INFORMATIONAL |
|
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 4542 | Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite |
| |
| Authors: | F. Baker, J. Polk. |
| Date: | May 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5865 |
| Status: | INFORMATIONAL |
|
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 4556 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
| Authors: | L. Zhu, B. Tung. |
| Date: | June 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6112 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6309 |
| Status: | PROPOSED STANDARD |
|
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 4585 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) |
| |
| Authors: | J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. |
| Date: | July 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5506 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Babiarz, K. Chan, F. Baker. |
| Date: | August 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5865 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | E. Mannie, D. Papadimitriou. |
| Date: | August 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3946 |
| Updated by: | RFC 6344 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6247 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
|
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 4749 | RTP Payload Format for the G.729.1 Audio Codec |
| |
| Authors: | A. Sollaud. |
| Date: | October 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 5459 |
| Status: | PROPOSED STANDARD |
|
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 4761 | Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling |
| |
| Authors: | K. Kompella, Ed., Y. Rekhter, Ed.. |
| Date: | January 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | S. Floyd. |
| Date: | November 2006 |
| Formats: | txt pdf |
| Updated by: | RFC 6040 |
| Also: | BCP 0124 |
| Status: | BEST CURRENT PRACTICE |
|
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 |
| |
| Authors: | H. Schulzrinne. |
| Date: | November 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4676 |
| Updated by: | RFC 5774 |
| Status: | PROPOSED STANDARD |
|
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 4788 | Enhancements to RTP Payload Formats for EVRC Family Codecs |
| |
| Authors: | Q. Xie, R. Kapoor. |
| Date: | January 2007 |
| Formats: | txt pdf |
| Updates: | RFC 3558 |
| Updated by: | RFC 5188 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | C. Daboo, B. Desruisseaux, L. Dusseault. |
| Date: | March 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 5689 |
| Status: | PROPOSED STANDARD |
|
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 4844 | The RFC Series and RFC Editor |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | July 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 5741 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Updated by: | RFC 5744 |
| Status: | INFORMATIONAL |
|
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 4861 | Neighbor Discovery for IP version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson, H. Soliman. |
| Date: | September 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2461 |
| Updated by: | RFC 5942 |
| Status: | DRAFT STANDARD |
|
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 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Updates: | RFC 3471 |
| Updated by: | RFC 4873 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6510 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer. |
| Date: | November 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1991, RFC 2440 |
| Updated by: | RFC 5581 |
| Status: | PROPOSED STANDARD |
|
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 4918 | HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) |
| |
| Authors: | L. Dusseault, Ed.. |
| Date: | June 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2518 |
| Updated by: | RFC 5689 |
| Status: | PROPOSED STANDARD |
|
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 4944 | Transmission of IPv6 Packets over IEEE 802.15.4 Networks |
| |
| Authors: | G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. |
| Date: | September 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 6282 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Klensin, Y. Ko. |
| Date: | July 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6530 |
| Updated by: | RFC 5336 |
| Status: | INFORMATIONAL |
|
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 |
| |
| Authors: | R. Siemborski, Ed., A. Melnikov, Ed.. |
| Date: | July 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2554 |
| Updates: | RFC 3463 |
| Updated by: | RFC 5248 |
| Status: | PROPOSED STANDARD |
|
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 4969 | IANA Registration for vCard Enumservice |
| |
| Authors: | A. Mayrhofer. |
| Date: | August 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | D. Papadimitriou, A. Farrel. |
| Date: | August 2007 |
| Formats: | txt pdf |
| Updates: | RFC 3473 |
| Updated by: | RFC 6001 |
| Status: | PROPOSED STANDARD |
|
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 4979 | IANA Registration for Enumservice 'XMPP' |
| |
| Authors: | A. Mayrhofer. |
| Date: | August 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 5028 | A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services |
| |
| Authors: | R. Mahy. |
| Date: | October 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 5043 | Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation |
| |
| Authors: | C. Bestler, Ed., R. Stewart, Ed.. |
| Date: | October 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 6581 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6581 |
| Status: | PROPOSED STANDARD |
|
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 5085 | Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires |
| |
| Authors: | T. Nadeau, Ed., C. Pignataro, Ed.. |
| Date: | December 2007 |
| Formats: | txt pdf |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
|
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 5092 | IMAP URL Scheme |
| |
| Authors: | A. Melnikov, Ed., C. Newman. |
| Date: | November 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2192 |
| Updates: | RFC 4467 |
| Updated by: | RFC 5593 |
| Status: | PROPOSED STANDARD |
|
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 5102 | Information Model for IP Flow Information Export |
| |
| Authors: | J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. |
| Date: | January 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 6313 |
| Status: | PROPOSED STANDARD |
|
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 5129 | Explicit Congestion Marking in MPLS |
| |
| Authors: | B. Davie, B. Briscoe, J. Tay. |
| Date: | January 2008 |
| Formats: | txt pdf |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 5872 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6253 |
| Status: | EXPERIMENTAL |
|
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 pdf |
| Updated by: | RFC 6543 |
| Status: | PROPOSED STANDARD |
|
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 5228 | Sieve: An Email Filtering Language |
| |
| Authors: | P. Guenther, Ed., T. Showalter, Ed.. |
| Date: | January 2008 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3028 |
| Updated by: | RFC 5229, RFC 5429 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | K. Homme. |
| Date: | January 2008 |
| Formats: | txt pdf |
| Updates: | RFC 5228 |
| Updated by: | RFC 5173 |
| Status: | PROPOSED STANDARD |
|
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 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 |
| |
|
|
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 5256 | Internet Message Access Protocol - SORT and THREAD Extensions |
| |
| Authors: | M. Crispin, K. Murchison. |
| Date: | June 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 5957 |
| Status: | PROPOSED STANDARD |
|
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 5267 | Contexts for IMAP4 |
| |
| Authors: | D. Cridland, C. King. |
| Date: | July 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 5465 |
| Status: | PROPOSED STANDARD |
|
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) |
| |
| Authors: | J. Schaad, M. Myers. |
| Date: | June 2008 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2797 |
| Updated by: | RFC 6402 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Schaad, M. Myers. |
| Date: | June 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 6402 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | J. Schaad, M. Myers. |
| Date: | June 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 6402 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 5301 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
| Authors: | D. McPherson, N. Shen. |
| Date: | October 2008 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2763 |
| Updated by: | RFC 6232 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | T. Li, H. Smit. |
| Date: | October 2008 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3784 |
| Updated by: | RFC 5307 |
| Status: | PROPOSED STANDARD |
|
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 5310 | IS-IS Generic Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. |
| Date: | February 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6233, RFC 6232 |
| Status: | PROPOSED STANDARD |
|
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 5333 | IANA Registration of Enumservices for Internet Calendaring |
| |
| Authors: | R. Mahy, B. Hoeneisen. |
| Date: | October 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
|
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 5357 | A Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz. |
| Date: | October 2008 |
| Formats: | txt pdf |
| Updated by: | RFC 5618, RFC 5938, RFC 6038 |
| Status: | PROPOSED STANDARD |
|
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 5410 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 |
| |
| Authors: | A. Jerichow, Ed., L. Piron. |
| Date: | January 2009 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4909 |
| Updated by: | RFC 6309 |
| Status: | INFORMATIONAL |
|
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 5420 | Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) |
| |
| Authors: | A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangarps. |
| Date: | February 2009 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4420 |
| Updates: | RFC 3209, RFC 3473 |
| Updated by: | RFC 6510 |
| Status: | PROPOSED STANDARD |
|
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 5443 | LDP IGP Synchronization |
| |
| Authors: | M. Jork, A. Atlas, L. Fang. |
| Date: | March 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6138 |
| Status: | INFORMATIONAL |
|
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 5451 | Message Header Field for Indicating Message Authentication Status |
| |
| Authors: | M. Kucherawy. |
| Date: | April 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6577 |
| Status: | PROPOSED STANDARD |
|
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 5470 | Architecture for IP Flow Information Export |
| |
| Authors: | G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6183 |
| Status: | INFORMATIONAL |
|
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 5544 | Syntax for Binding Documents with Time-Stamps |
| |
| Authors: | A. Santoni. |
| Date: | February 2010 |
| Formats: | txt pdf |
| Updated by: | RFC 5955 |
| Status: | INFORMATIONAL |
|
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) |
| |
| Authors: | B. Desruisseaux, Ed.. |
| Date: | September 2009 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2445 |
| Updated by: | RFC 5546 |
| Status: | PROPOSED STANDARD |
|
|
|
| |
| RFC 5560 | A One-Way Packet Duplication Metric |
| |
| Authors: | H. Uijterwaal. |
| Date: | May 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
|
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 5586 | MPLS Generic Associated Channel |
| |
|
|
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 |
| |
| Authors: | G. Fairhurst. |
| Date: | September 2009 |
| Formats: | txt pdf |
| Updates: | RFC 4340 |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
|
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 5622 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) |
| |
| Authors: | S. Floyd, E. Kohler. |
| Date: | August 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6323 |
| Status: | EXPERIMENTAL |
|
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 5644 | IP Performance Metrics (IPPM): Spatial and Multicast |
| |
| Authors: | E. Stephan, L. Liang, A. Morton. |
| Date: | October 2009 |
| Formats: | txt pdf |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
|
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 pdf |
| Updated by: | RFC 6089 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6128 |
| Status: | PROPOSED STANDARD |
|
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 5885 | Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) |
| |
| Authors: | T. Nadeau, Ed., C. Pignataro, Ed.. |
| Date: | June 2010 |
| Formats: | txt pdf |
| Updated by: | RFC 6478 |
| Status: | PROPOSED STANDARD |
|
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 5911 | New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME |
| |
| Authors: | P. Hoffman, J. Schaad. |
| Date: | June 2010 |
| Formats: | txt pdf |
| Updated by: | RFC 6268 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 6215 |
| Status: | INFORMATIONAL |
|
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 5959 | Algorithms for Asymmetric Key Package Content Type |
| |
| Authors: | S. Turner. |
| Date: | August 2010 |
| Formats: | txt pdf |
| Updated by: | RFC 6162 |
| Status: | PROPOSED STANDARD |
|
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 5996 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. |
| Date: | September 2010 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4306, RFC 4718 |
| Updated by: | RFC 5998 |
| Status: | PROPOSED STANDARD |
|
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 6033 | Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
| Authors: | S. Turner. |
| Date: | December 2010 |
| Formats: | txt pdf |
| Updated by: | RFC 6161 |
| Status: | PROPOSED STANDARD |
|
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 6043 | MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | J. Mattsson, T. Tian. |
| Date: | March 2011 |
| Formats: | txt pdf |
| Updated by: | RFC 6309 |
| Status: | INFORMATIONAL |
|
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 pdf |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6547 |
| Status: | PROPOSED STANDARD |
|
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 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 pdf |
| Updated by: | RFC 6623 |
| Status: | PROPOSED STANDARD |
|
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 6292 | Requirements for a Working Group Charter Tool |
| |
| Authors: | P. Hoffman. |
| Date: | June 2011 |
| Formats: | txt pdf |
| Updated by: | RFC 6433 |
| Status: | INFORMATIONAL |
|
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 6325 | Routing Bridges (RBridges): Base Protocol Specification |
| |
| Authors: | R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. |
| Date: | July 2011 |
| Formats: | txt pdf |
| Updated by: | RFC 6327, RFC 6439 |
| Status: | PROPOSED STANDARD |
|
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 6371 | Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks |
| |
| Authors: | I. Busi, Ed., D. Allan, Ed.. |
| Date: | September 2011 |
| Formats: | txt pdf |
| Updated by: | RFC 6435 |
| Status: | INFORMATIONAL |
|
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 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 pdf |
| Updated by: | RFC 6515, RFC 6625 |
| Status: | PROPOSED STANDARD |
|
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 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". |
|
