| |
| 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 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 |
| 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 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 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 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 |
| Updated by: | RFC 1644 |
| Status: | INFORMATIONAL |
|
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 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 2113 | IP Router Alert Option |
| |
| Authors: | D. Katz. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 5350 |
| Status: | PROPOSED STANDARD |
|
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 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 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 |
| |
| Authors: | R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 2750, RFC 3936, RFC 4495 |
| Status: | PROPOSED STANDARD |
|
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 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 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 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 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 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 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. |
| Date: | June 1999 |
| Formats: | txt pdf ps |
| Obsoletes: | RFC 2068 |
| Updated by: | RFC 2817, RFC 5785 |
| Status: | DRAFT STANDARD |
|
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 |
| |
| Authors: | M. Crawford. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 4592 |
| Status: | PROPOSED STANDARD |
|
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 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 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 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 |
| 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 3007 | Secure Domain Name System (DNS) Dynamic Update |
| |
|
|
This document proposes a method for performing secure Domain NameSystem (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. |
|
| |
| 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 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 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 3174 | US Secure Hash Algorithm 1 (SHA1) |
| |
| Authors: | D. Eastlake 3rd, P. Jones. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Updated by: | RFC 4634 |
| 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 |
| 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 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) |
| |
| Authors: | R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Updated by: | RFC 4361, RFC 5494 |
| Status: | PROPOSED STANDARD |
|
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 |
| |
| Authors: | C. Perkins, Ed.. |
| Date: | August 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3220 |
| Updated by: | RFC 4721 |
| 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 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: |
| |
