| |
| RFC 3 | Documentation conventions |
| |
|
| |
| RFC 10 | Documentation conventions |
| |
|
| |
| RFC 11 | Implementation of the Host - Host Software Procedures in GORDO |
| |
|
| |
| RFC 16 | M.I.T |
| |
|
| |
| RFC 61 | Note on Interprocess Communication in a Resource Sharing Computer Network |
| |
|
| |
| RFC 66 | NIC - third level ideas and other noise |
| |
|
| |
| RFC 80 | Protocols and Data Formats |
| |
|
| |
| RFC 88 | NETRJS: A third level protocol for Remote Job Entry |
| |
|
| |
| RFC 95 | Distribution of NWG/RFC's through the NIC |
| |
|
| |
| RFC 123 | Proffered Official ICP |
| |
|
| |
| RFC 127 | Comments on RFC 123 |
| |
|
| |
| RFC 132 | Typographical Error in RFC 107 |
| |
|
| |
| RFC 143 | Regarding proffered official ICP |
| |
|
| |
| RFC 145 | Initial Connection Protocol Control Commands |
| |
|
| |
| RFC 155 | ARPA Network mailing lists |
| |
|
| |
| RFC 158 | Telnet Protocol: A Proposed Document |
| |
|
| |
| RFC 160 | RFC brief list |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | May 1971 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0200, RFC 0999 |
| Updates: | NIC_6716 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0160 |
|
|
|
| |
| RFC 168 | ARPA Network mailing lists |
| |
|
| |
| RFC 170 | RFC List by Number |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | June 1971 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0200 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0170 |
|
|
|
| |
| RFC 171 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0264 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0171 |
|
|
|
| |
| RFC 172 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0265 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0172 |
|
|
|
| |
| RFC 189 | Interim NETRJS specifications |
| |
|
| |
| RFC 193 | NETWORK CHECKOUT |
| |
|
| |
| RFC 196 | Mail Box Protocol |
| |
|
| |
| RFC 198 | Site Certification - Lincoln Labs 360/67 |
| |
|
| |
| RFC 200 | RFC list by number |
| |
|
| |
| RFC 207 | September Network Working Group meeting |
| |
|
| |
| RFC 211 | ARPA Network Mailing Lists |
| |
|
| |
| RFC 221 | Mail Box Protocol: Version 2 |
| |
|
| |
| RFC 226 | Standardization of host mnemonics |
| |
|
| |
| RFC 229 | Standard host names |
| |
|
| |
| RFC 235 | Site status |
| |
|
| |
| RFC 237 | NIC view of standard host names |
| |
|
| |
| RFC 240 | Site Status |
| |
|
| |
| RFC 243 | Network and data sharing bibliography |
| |
|
| |
| RFC 252 | Network host status |
| |
|
| |
| RFC 255 | Status of network hosts |
| |
|
| |
| RFC 264 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. |
| Date: | January 1972 |
| Formats: | txt json html |
| Obsoletes: | RFC 0171 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0310 |
| Also: | RFC 0265 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0264 |
|
|
|
| |
| RFC 265 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | November 1971 |
| Formats: | txt json html |
| Obsoletes: | RFC 0172 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0281, RFC 0294, RFC 0310 |
| Also: | RFC 0264 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0265 |
|
|
|
| |
| RFC 266 | Network host status |
| |
|
| |
| RFC 267 | Network Host Status |
| |
|
| |
| RFC 287 | Status of Network Hosts |
| |
|
| |
| RFC 288 | Network host status |
| |
|
| |
| RFC 289 | What we hope is an official list of host names |
| |
|
| |
| RFC 292 | Graphics Protocol: Level 0 only |
| |
| Authors: | J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. |
| Date: | January 1972 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0493 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0292 |
|
|
|
| |
| RFC 293 | Network Host Status |
| |
|
| |
| RFC 298 | Network host status |
| |
|
| |
| RFC 300 | ARPA Network mailing lists |
| |
|
| |
| RFC 303 | ARPA Network mailing lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | March 1972 |
| Formats: | txt html json |
| Obsoletes: | RFC 0300 |
| Obsoleted by: | RFC 0329 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0303 |
|
|
|
| |
| RFC 306 | Network host status |
| |
|
| |
| RFC 315 | Network Host Status |
| |
|
| |
| RFC 317 | Official Host-Host Protocol Modification: Assigned Link Numbers |
| |
|
| |
| RFC 326 | Network Host Status |
| |
|
| |
| RFC 329 | ARPA Network Mailing Lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | May 1972 |
| Formats: | txt json html |
| Obsoletes: | RFC 0303 |
| Obsoleted by: | RFC 0363 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0329 |
|
|
|
| |
| RFC 331 | IMP System Change Notification |
| |
|
| |
| RFC 332 | Network Host Status |
| |
|
| |
| RFC 342 | Network Host Status |
| |
|
| |
| RFC 343 | IMP System change notification |
| |
|
| |
| RFC 344 | Network Host Status |
| |
|
| |
| RFC 349 | Proposed Standard Socket Numbers |
| |
|
| |
| RFC 353 | Network host status |
| |
|
| |
| RFC 354 | File Transfer Protocol |
| |
|
| |
| RFC 360 | Proposed Remote Job Entry Protocol |
| |
|
| |
| RFC 362 | Network Host Status |
| |
|
| |
| RFC 363 | ARPA Network mailing lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | August 1972 |
| Formats: | txt json html |
| Obsoletes: | RFC 0329 |
| Obsoleted by: | RFC 0402 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0363 |
|
|
|
| |
| RFC 366 | Network Host Status |
| |
|
| |
| RFC 367 | Network host status |
| |
|
| |
| RFC 378 | Traffic statistics (July 1972) |
| |
|
| |
| RFC 389 | UCLA Campus Computing Network Liaison Staff for ARPA Network |
| |
|
| |
| RFC 399 | SMFS Login and Logout |
| |
|
| |
| RFC 433 | Socket number list |
| |
|
| |
| RFC 434 | IMP/TIP memory retrofit schedule |
| |
|
| |
| RFC 447 | IMP/TIP memory retrofit schedule |
| |
|
| |
| RFC 503 | Socket number list |
| |
|
| |
| RFC 542 | File Transfer Protocol |
| |
|
| |
| RFC 599 | Update on NETRJS |
| |
|
| |
| RFC 604 | Assigned link numbers |
| |
|
|
Modifies official host-host protocol. Replaces RFC 377. |
|
| |
| RFC 607 | Comments on the File Transfer Protocol |
| |
|
|
An old version; see RFC 624; see also RFCs 614, 542 and 640. |
|
| |
| RFC 608 | Host names on-line |
| |
|
|
Response to RFC 606; see also RFCs 627, 625 and 623. |
|
| |
| RFC 615 | Proposed Network Standard Data Pathname syntax |
| |
|
| |
| RFC 633 | IMP/TIP preventive maintenance schedule |
| |
|
|
An old version; see RFC 638. |
|
| |
| RFC 651 | Revised Telnet status option |
| |
|
| |
| RFC 675 | Specification of Internet Transmission Control Program |
| |
| Authors: | V. Cerf, Y. Dalal, C. Sunshine. |
| Date: | December 1974 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7805 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0675 |
|
The first detailed specification of TCP; see RFC 793. |
|
| |
| 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 698 | Telnet extended ASCII option |
| |
|
|
Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs. |
|
| |
| RFC 721 | Out-of-Band Control Signals in a Host-to-Host Protocol |
| |
|
| |
| RFC 724 | Proposed official standard for the format of ARPA Network messages |
| |
| Authors: | D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. |
| Date: | May 1977 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0733 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0724 |
|
|
|
| |
| RFC 729 | Telnet byte macro option |
| |
|
| |
| RFC 731 | Telnet Data Entry Terminal option |
| |
|
| |
| RFC 733 | Standard for the format of ARPA network text messages |
| |
| Authors: | D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. |
| Date: | November 1977 |
| Formats: | txt html json |
| Obsoletes: | RFC 0724 |
| Obsoleted by: | RFC 0822 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0733 |
|
|
|
| |
| RFC 739 | Assigned numbers |
| |
|
| |
| RFC 742 | NAME/FINGER Protocol |
| |
|
| |
| RFC 750 | Assigned numbers |
| |
|
| |
| RFC 755 | Assigned numbers |
| |
|
| |
| RFC 758 | Assigned numbers |
| |
|
| |
| RFC 760 | DoD standard Internet Protocol |
| |
|
| |
| RFC 761 | DoD standard Transmission Control Protocol |
| |
|
| |
| RFC 762 | Assigned numbers |
| |
|
| |
| RFC 764 | Telnet Protocol specification |
| |
|
| |
| RFC 765 | File Transfer Protocol specification |
| |
|
| |
| RFC 766 | Internet Protocol Handbook: Table of contents |
| |
|
| |
| RFC 770 | Assigned numbers |
| |
|
| |
| RFC 772 | Mail Transfer Protocol |
| |
|
| |
| RFC 776 | Assigned numbers |
| |
|
| |
| RFC 777 | Internet Control Message Protocol |
| |
|
| |
| RFC 780 | Mail Transfer Protocol |
| |
|
| |
| RFC 783 | TFTP Protocol (revision 2) |
| |
|
| |
| RFC 788 | Simple Mail Transfer Protocol |
| |
|
| |
| RFC 790 | Assigned numbers |
| |
|
| |
| RFC 793 | Transmission Control Protocol |
| |
|
| |
| RFC 802 | ARPANET 1822L Host Access Protocol |
| |
|
|
This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851. |
|
| |
| RFC 806 | Proposed Federal Information Processing Standard: Specification for message format for computer based message systems |
| |
| Authors: | National Bureau of Standards. |
| Date: | September 1981 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0841 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0806 |
|
This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841. |
|
| |
| RFC 810 | DoD Internet host table specification |
| |
|
|
This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608. |
|
| |
| RFC 811 | Hostnames Server |
| |
| Authors: | K. Harrenstien, V. White, E.J. Feinler. |
| Date: | March 1982 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0953 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0811 |
|
This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment. |
|
| |
| RFC 812 | NICNAME/WHOIS |
| |
|
|
This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory. |
|
| |
| RFC 813 | Window and Acknowledgement Strategy in TCP |
| |
|
|
This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended. |
|
| |
| RFC 816 | Fault isolation and recovery |
| |
|
|
This RFC describes the portion of fault isolation and recovery which is the responsibility of the host. |
|
| |
| RFC 820 | Assigned numbers |
| |
|
|
This RFC is an old version, see RFC 870. |
|
| |
| RFC 821 | Simple Mail Transfer Protocol |
| |
|
|
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772. |
|
| |
| 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 825 | Request for comments on Requests For Comments |
| |
|
|
This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs. |
|
| |
| RFC 832 | Who talks TCP? |
| |
|
|
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 2-Dec-82. The tests were run on 7-Dec-82. |
|
| |
| RFC 833 | Who talks TCP? |
| |
|
|
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 2-Dec-82. The tests were run on 14-Dec-82. |
|
| |
| RFC 834 | Who talks TCP? |
| |
|
|
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 2-Dec-82. The tests were run on 22-Dec-82. |
|
| |
| RFC 835 | Who talks TCP? |
| |
|
|
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 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83. |
|
| |
| RFC 836 | Who talks TCP? |
| |
|
|
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 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83. |
|
| |
| RFC 837 | Who talks TCP? |
| |
|
|
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 31-Dec-82. The tests were run on 11-Jan-83. |
|
| |
| RFC 838 | Who talks TCP? |
| |
|
|
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 31-Dec-82. The tests were run on 18-Jan-83. |
|
| |
| RFC 839 | Who talks TCP? |
| |
|
|
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 31-Dec-82. The tests were run on 25-Jan-83. |
|
| |
| RFC 840 | Official protocols |
| |
|
|
This RFC has been revised, see RFC 880. |
|
| |
| RFC 842 | Who talks TCP? - survey of 1 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 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA. |
|
| |
| 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 845 | Who talks TCP? - survey of 15 February 1983 |
| |
|
|
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 15-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 846 | Who talks TCP? - survey of 22 February 1983 |
| |
|
|
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 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 850 | Standard for interchange of USENET messages |
| |
|
|
This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on. |
|
| |
| RFC 851 | ARPANET 1822L Host Access Protocol |
| |
|
|
This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802. |
|
| |
| RFC 870 | Assigned numbers |
| |
|
|
This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604. |
|
| |
| RFC 877 | Standard for the transmission of IP datagrams over public data networks |
| |
|
|
This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks. |
|
| |
| RFC 879 | The TCP Maximum Segment Size and Related Topics |
| |
|
|
This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers". |
|
| |
| RFC 880 | Official protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840. |
|
| |
| 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 884 | Telnet terminal type option |
| |
|
|
This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol. |
|
| |
| RFC 892 | ISO Transport Protocol specification |
| |
| Authors: | International Organization for Standardization. |
| Date: | December 1983 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0905 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0892 |
|
This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date. |
|
| |
| RFC 896 | Congestion Control in IP/TCP Internetworks |
| |
|
|
This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards. |
|
| |
| RFC 900 | Assigned Numbers |
| |
|
|
This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997. |
|
| |
| RFC 901 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991. |
|
| |
| RFC 912 | Authentication service |
| |
|
|
This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server. |
|
| |
| RFC 918 | Post Office Protocol |
| |
|
|
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP. |
|
| |
| RFC 923 | Assigned numbers |
| |
|
|
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997. |
|
| |
| RFC 924 | Official ARPA-Internet protocols for connecting personal computers to the Internet |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 926 | Protocol for providing the connectionless mode network services |
| |
| Authors: | International Organization for Standardization. |
| Date: | December 1984 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0994 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0926 |
|
This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet. |
|
| |
| RFC 930 | Telnet terminal type option |
| |
|
|
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. |
|
| |
| RFC 931 | Authentication server |
| |
|
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. |
|
| |
| RFC 943 | 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 RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 944 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 945 | DoD statement on the NRC report |
| |
|
|
In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only. |
|
| |
| RFC 948 | Two methods for the transmission of IP datagrams over IEEE 802.3 networks |
| |
|
|
This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 954 | NICNAME/WHOIS |
| |
|
|
This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812. |
|
| |
| RFC 958 | Network Time Protocol (NTP) |
| |
|
|
This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 960 | Assigned numbers |
| |
|
|
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 961 | Official ARPA-Internet protocols |
| |
|
|
This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 966 | Host groups: A multicast extension to the Internet Protocol |
| |
| Authors: | S.E. Deering, D.R. Cheriton. |
| Date: | December 1985 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0988 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0966 |
|
This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988. |
|
| |
| RFC 969 | NETBLT: A bulk data transfer protocol |
| |
| Authors: | D.D. Clark, M.L. Lambert, L. Zhang. |
| Date: | December 1985 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0998 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0969 |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998. |
|
| |
| RFC 973 | Domain system changes and observations |
| |
|
|
This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system. |
|
| |
| RFC 974 | Mail routing and the domain system |
| |
|
|
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. |
|
| |
| RFC 977 | Network News Transfer Protocol |
| |
| Authors: | B. Kantor, P. Lapsley. |
| Date: | February 1986 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3977 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0977 |
|
NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 983 | ISO transport arrives on top of the TCP |
| |
|
|
This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. |
|
| |
| RFC 984 | PCMAIL: A distributed mail system for personal computers |
| |
|
|
This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993. |
|
| |
| RFC 985 | Requirements for Internet gateways - draft |
| |
| Authors: | National Science Foundation, Network Technical Advisory Group. |
| Date: | May 1986 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1009 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0985 |
|
This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification. |
|
| |
| RFC 986 | Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol |
| |
|
|
This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| 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 988 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. |
|
| |
| RFC 989 | Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures |
| |
|
|
This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated. |
|
| |
| 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 991 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924. |
|
| |
| RFC 993 | PCMAIL: A distributed mail system for personal computers |
| |
|
|
This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984. |
|
| |
| RFC 997 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900. |
|
| |
| RFC 999 | Requests For Comments summary notes: 900-999 |
| |
|
| |
| RFC 1009 | Requirements for Internet gateways |
| |
|
|
This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community. |
|
| |
| RFC 1010 | Assigned numbers |
| |
|
|
This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations. |
|
| |
| RFC 1020 | Internet numbers |
| |
|
|
This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997. |
|
| |
| RFC 1023 | HEMS monitoring and control language |
| |
|
|
This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1. |
|
| |
| 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 1036 | Standard for interchange of USENET messages |
| |
|
|
This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1038 | Draft revised IP security option |
| |
|
|
This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol". |
|
| |
| RFC 1040 | Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures |
| |
|
|
This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated. |
|
| |
| RFC 1048 | BOOTP vendor information extensions |
| |
|
|
This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought. |
|
| |
| RFC 1050 | RPC: Remote Procedure Call Protocol specification |
| |
|
|
This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time. |
|
| |
| RFC 1051 | Standard for the transmission of IP datagrams and ARP packets over ARCNET networks |
| |
|
|
This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community. |
|
| |
| RFC 1054 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988. |
|
| |
| RFC 1059 | Network Time Protocol (version 1) specification and implementation |
| |
|
|
This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol. |
|
| |
| 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 1062 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community. |
|
| |
| RFC 1063 | IP MTU discovery options |
| |
| Authors: | J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie. |
| Date: | July 1988 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1191 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 1063 |
|
A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol. |
|
| |
| RFC 1064 | Interactive Mail Access Protocol: Version 2 |
| |
|
|
This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 1065 | Structure and identification of management information for TCP/IP-based internets |
| |
| Authors: | K. McCloghrie, M.T. Rose. |
| Date: | August 1988 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1155 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 1065 |
|
This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1066 | Management Information Base for network management of TCP/IP-based internets |
| |
|
|
This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1067 | Simple Network Management Protocol |
| |
| Authors: | J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. |
| Date: | August 1988 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1098 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 1067 |
|
This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1072 | TCP extensions for long-delay paths |
| |
|
|
This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance. |
|
| |
| RFC 1078 | TCP port service Multiplexer (TCPMUX) |
| |
|
|
This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'. |
|
| |
| RFC 1080 | Telnet remote flow control option |
| |
|
|
This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard. |
|
| |
| RFC 1081 | Post Office Protocol: Version 3 |
| |
|
|
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1083 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | December 1988 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1100 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1083 |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. |
|
| |
| RFC 1084 | BOOTP vendor information extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought. |
|
| |
| RFC 1089 | SNMP over Ethernet |
| |
| Authors: | M. Schoffstall, C. Davin, M. Fedor, J. Case. |
| Date: | February 1989 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4789 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 1089 |
|
This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer. |
|
| |
| RFC 1095 | Common Management Information Services and Protocol over TCP/IP (CMOT) |
| |
|
|
This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet. |
|
| |
| RFC 1098 | Simple Network Management Protocol (SNMP) |
| |
|
|
This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet. |
|
| |
| RFC 1100 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | April 1989 |
| Formats: | txt json html |
| Obsoletes: | RFC 1083 |
| Obsoleted by: | RFC 1130 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1100 |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89. |
|
| |
| RFC 1103 | Proposed standard for the transmission of IP datagrams over FDDI Networks |
| |
|
|
This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK] |
|
| |
| RFC 1105 | Border Gateway Protocol (BGP) |
| |
|
|
This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] |
|
| |
| RFC 1106 | TCP big window and NAK options |
| |
|
|
Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product. The main issue that still needs to be solved is congestion versus noise. This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks. Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use. |
|
| |
| RFC 1110 | Problem with the TCP big window option |
| |
|
|
The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets. In such networks, the window size must not be increased without a similar increase in the sequence number space. Therefore, a different approach to big windows should be taken in the Internet. |
|
| |
| RFC 1111 | Request for comments on Request for Comments: Instructions to RFC authors |
| |
|
|
This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard. |
|
| |
| RFC 1113 | Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures |
| |
|
|
This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK] |
|
| |
| RFC 1114 | Privacy enhancement for Internet electronic mail: Part II - certificate-based key management |
| |
|
|
This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK] |
|
| |
| RFC 1115 | Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers |
| |
|
|
This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK] |
|
| |
| RFC 1116 | Telnet Linemode option |
| |
|
|
Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK] |
|
| |
| RFC 1117 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community. |
|
| |
| RFC 1119 | Network Time Protocol (version 2) specification and implementation |
| |
|
|
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK] |
|
| |
| RFC 1120 | Internet Activities Board |
| |
|
|
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1130 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | October 1989 |
| Formats: | txt json html |
| Obsoletes: | RFC 1100 |
| Obsoleted by: | RFC 1140 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1130 |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). |
|
| |
| RFC 1131 | OSPF specification |
| |
|
|
This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK] |
|
| |
| RFC 1134 | Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links |
| |
|
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed. |
|
| |
| 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 1139 | Echo function for ISO 8473 |
| |
|
|
This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item.
When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. |
|
| |
| RFC 1140 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | May 1990 |
| Formats: | txt html json |
| Obsoletes: | RFC 1130 |
| Obsoleted by: | RFC 1200 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1140 |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90. |
|
| |
| RFC 1142 | OSI IS-IS Intra-domain Routing Protocol |
| |
|
|
This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard. |
|
| |
| RFC 1145 | TCP alternate checksum options |
| |
|
|
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. |
|
| |
| RFC 1146 | TCP alternate checksum options |
| |
|
|
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145. |
|
| |
| RFC 1147 | FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices |
| |
|
|
The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained. |
|
| |
| RFC 1148 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
This 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 edition includes material lost in editing. |
|
| |
| RFC 1150 | FYI on FYI: Introduction to the FYI Notes |
| |
|
|
This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.] |
|
| |
| RFC 1154 | Encoding header field for internet messages |
| |
|
|
This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement). |
|
| |
| RFC 1158 | 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. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK] |
|
| |
| RFC 1159 | Message Send Protocol |
| |
|
|
This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol. |
|
| |
| RFC 1161 | SNMP over OSI |
| |
|
|
This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community, |
|
| |
| RFC 1162 | Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community. |
|
| |
| RFC 1163 | Border Gateway Protocol (BGP) |
| |
|
|
This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1164 | Application of the Border Gateway Protocol in the Internet |
| |
| Authors: | J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. |
| Date: | June 1990 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1268 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1164 |
|
This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1171 | Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links |
| |
|
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed. |
|
| |
| RFC 1172 | Point-to-Point Protocol (PPP) initial configuration options |
| |
|
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of
1) a method for encapsulating datagrams over serial links,2) an extensible Link Control Protocol (LCP), and3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called theIP Control Protocol, IPCP) are defined in The Point-to-Point Protocol(PPP) [1].
This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme. |
|
| |
| RFC 1177 | FYI on Questions and Answers: Answers to commonly asked "new internet user" questions |
| |
| Authors: | G.S. Malkin, A.N. Marine, J.K. Reynolds. |
| Date: | August 1990 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1206 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1177 |
|
This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.] |
|
| |
| RFC 1185 | TCP Extension for High-Speed Paths |
| |
| Authors: | V. Jacobson, R.T. Braden, L. Zhang. |
| Date: | October 1990 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1323 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1185 |
|
This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1186 | MD4 Message Digest Algorithm |
| |
|
|
This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1190 | Experimental Internet Stream Protocol: Version 2 (ST-II) |
| |
| Authors: | C. Topolcic. |
| Date: | October 1990 |
| Formats: | txt html json |
| Obsoletes: | IEN119 |
| Obsoleted by: | RFC 1819 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1190 |
|
This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1194 | Finger User Information Protocol |
| |
|
|
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. |
|
| |
| RFC 1196 | Finger User Information Protocol |
| |
|
|
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. |
|
| |
| RFC 1200 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | April 1991 |
| Formats: | txt html json |
| Obsoletes: | RFC 1140 |
| Obsoleted by: | RFC 1250 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1200 |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. |
|
| |
| RFC 1206 | FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4] |
|
| |
| RFC 1218 | Naming scheme for c=US |
| |
|
|
This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1220 | Point-to-Point Protocol extensions for bridging |
| |
|
|
This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK] |
|
| |
| RFC 1225 | Post Office Protocol: Version 3 |
| |
|
|
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK] |
|
| |
| RFC 1228 | SNMP-DPI: Simple Network Management Protocol Distributed Program Interface |
| |
|
|
This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1229 | Extensions to the generic-interface MIB |
| |
|
|
This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK] |
|
| |
| RFC 1231 | IEEE 802.5 Token Ring MIB |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] |
|
| |
| RFC 1232 | Definitions of managed objects for the DS1 Interface type |
| |
|
| |
| RFC 1233 | Definitions of managed objects for the DS3 Interface type |
| |
|
|
This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1237 | Guidelines for OSI NSAP Allocation in the Internet |
| |
|
|
This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK] |
|
| |
| RFC 1243 | AppleTalk Management Information Base |
| |
|
|
This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1244 | Site Security Handbook |
| |
| Authors: | J.P. Holbrook, J.K. Reynolds. |
| Date: | July 1991 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2196 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1244 |
|
This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8] |
|
| |
| RFC 1247 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1248 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK] |
|
| |
| RFC 1250 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1251 | Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members |
| |
|
|
This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9] |
|
| |
| RFC 1252 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] |
|
| |
| RFC 1253 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] |
|
| |
| RFC 1255 | A Naming Scheme for c=US |
| |
|
|
This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1258 | BSD Rlogin |
| |
|
|
The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1264 | Internet Engineering Task Force Internet Routing Protocol Standardization Criteria |
| |
|
|
This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard. |
|
| |
| RFC 1268 | Application of the Border Gateway Protocol in the Internet |
| |
|
|
This document, together with its companion document, "A BorderGateway Protocol (BGP-3)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol (BGP-3)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (iwg@rice.edu). |
|
| |
| RFC 1269 | Definitions of Managed Objects for the Border Gateway Protocol: Version 3 |
| |
| Authors: | S. Willis, J.W. Burruss. |
| Date: | October 1991 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4273 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1269 |
|
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 the Border Gateway Protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1271 | Remote Network Monitoring Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK] |
|
| |
| RFC 1274 | The COSINE and Internet X.500 Schema |
| |
| Authors: | P. Barker, S. Kille. |
| Date: | November 1991 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4524 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1274 |
|
This document suggests an X.500 Directory Schema, or NamingArchitecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema.
This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements. Proformas to support this process are included.
Corrections and additions to the schema should be sent to na- update@cs.ucl.ac.uk list, as described within. |
|
| |
| RFC 1280 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1283 | SNMP over OSI |
| |
|
|
This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard. |
|
| |
| RFC 1284 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
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 ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1286 | Definitions of Managed Objects for Bridges |
| |
| Authors: | E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. |
| Date: | December 1991 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1493, RFC 1525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1286 |
|
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 bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK] |
|
| |
| RFC 1289 | DECnet Phase IV MIB Extensions |
| |
|
|
This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets(RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combinedTCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the InternetEngineering Task Force (IETF). |
|
| |
| RFC 1290 | There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places |
| |
|
|
This document was presented at the 1991 ACM SIGUCCS User ServicesConference. It appears here in its updated form.
There is a wealth of information on the network. In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.
The ultimate goal is to make the route to these sources of information invisible to the user. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer. |
|
| |
| RFC 1292 | A Catalog of Available X.500 Implementations |
| |
|
|
The goal of this document is to provide information regarding the availability and capability of implementations of X.500. Comments and critiques of this document, and new or updated descriptions ofX.500 implementations are welcome. Send them to the DirectoryInformation Services Infrastructure (DISI) Working Group(disi@merit.edu) or to the editors. |
|
| |
| RFC 1293 | Inverse Address Resolution Protocol |
| |
| Authors: | T. Bradley, C. Brown. |
| Date: | January 1992 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2390 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1293 |
|
This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK] |
|
| |
| RFC 1294 | Multiprotocol Interconnect over Frame Relay |
| |
|
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK] |
|
| |
| RFC 1295 | User Bill of Rights for entries and listings in the Public Directory |
| |
| Authors: | The North American Directory Forum. |
| Date: | January 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1417 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1295 |
|
This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).
User Bill of Rights for entries and listings in the Public Directory
The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in thePublic Directory. As a user, you have:
I. The right not to be listed.
II. The right to have you or your agent informed when your entry is created.
III. The right to examine your entry.
IV. The right to correct inaccurate information in your entry.
V. The right to remove specific information from your entry.
VI. The right to be assured that your listing in thePublic Directory will comply with US or Canadian law regulating privacy or access information.
VII. The right to expect timely fulfillment of these rights. |
|
| |
| RFC 1298 | SNMP over IPX |
| |
| Authors: | R. Wormley, S. Bostock. |
| Date: | February 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1420 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1298 |
|
This memo defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. |
|
| |
| RFC 1304 | Definitions of Managed Objects for the SIP Interface Type |
| |
| Authors: | T. Cox, Ed., K. Tesink, Ed.. |
| Date: | February 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1694 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1304 |
|
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 SIP (SMDS InterfaceProtocol) objects. |
|
| |
| RFC 1305 | Network Time Protocol (Version 3) Specification, Implementation and Analysis |
| |
|
|
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK] |
|
| |
| RFC 1310 | The Internet Standards Process |
| |
|
|
This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK] |
|
| |
| RFC 1315 | Management Information Base for Frame Relay DTEs |
| |
| Authors: | C. Brown, F. Baker, C. Carvalho. |
| Date: | April 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2115 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1315 |
|
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 Frame Relay. |
|
| |
| RFC 1316 | Definitions of Managed Objects for Character Stream Devices |
| |
|
|
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 the management of character stream devices. [STANDARDS-TRACK] |
|
| |
| RFC 1317 | Definitions of Managed Objects for RS-232-like Hardware Devices |
| |
|
|
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 the management of RS-232-like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1318 | Definitions of Managed Objects for Parallel-printer-like Hardware Devices |
| |
|
|
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 the management of parallel-printer- like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1319 | The MD2 Message-Digest Algorithm |
| |
|
|
This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1320 | The MD4 Message-Digest Algorithm |
| |
|
|
This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1323 | TCP Extensions for High Performance |
| |
|
|
This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms:RTTM (Round Trip Time Measurement) and PAWS (Protect Against WrappedSequences). Selective acknowledgments are not included in this memo.
This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs. |
|
| |
| RFC 1325 | FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| 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 1331 | The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links |
| |
|
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating datagrams over serial links.
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 encapsulation scheme, together with thePPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1333 | PPP Link Quality Monitoring |
| |
|
|
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, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.
This document defines a protocol for generating Link-Quality-Reports.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1334 | PPP Authentication Protocols |
| |
| Authors: | B. Lloyd, W. Simpson. |
| Date: | October 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1994 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1334 |
|
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, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines two protocols for Authentication: the PasswordAuthentication Protocol and the Challenge-Handshake AuthenticationProtocol. This memo is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1338 | Supernetting: an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | June 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1338 |
|
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. |
|
| |
| RFC 1340 | 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 a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. |
|
| |
| RFC 1341 | MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 1342 | Representation of Non-ASCII Text in Internet Message Headers |
| |
|
|
This memo describes an extension to the message format defined in [1](known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC822 message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1341. |
|
| |
| RFC 1348 | DNS NSAP RRs |
| |
|
|
This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1349 | Type of Service in the Internet Protocol Suite |
| |
|
|
This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK] |
|
| |
| RFC 1354 | IP Forwarding Table MIB |
| |
|
|
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 routes in the IPInternet.
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy. |
|
| |
| RFC 1357 | A Format for E-mailing Bibliographic Records |
| |
|
|
This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). |
|
| |
| RFC 1358 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1360 | IAB Official Protocol Standards |
| |
|
| |
| RFC 1361 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 1362 | Novell IPX over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. |
|
| |
| RFC 1364 | BGP OSPF Interaction |
| |
|
|
This memo defines the various criteria to be used when designingAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP. |
|
| |
| RFC 1366 | Guidelines for Management of IP Address Space |
| |
|
|
This document has been reviewed by the Federal Engineering Task Force(FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1367 | Schedule for IP Address Space Management Guidelines |
| |
|
|
This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1368 | Definition of Managed Objects for IEEE 802.3 Repeater Devices |
| |
| Authors: | D. McMaster, K. McCloghrie. |
| Date: | October 1992 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1516 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1368 |
|
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 IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs." |
|
| |
| RFC 1374 | IP and ARP on HIPPI |
| |
| Authors: | J. Renwick, A. Nicholson. |
| Date: | October 1992 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2834 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1374 |
|
The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP onHIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. |
|
| |
| RFC 1376 | The PPP DECnet Phase IV Control Protocol (DNCP) |
| |
|
|
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 configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). |
|
| |
| RFC 1379 | Extending TCP for Transactions -- Concepts |
| |
|
|
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1384 | Naming Guidelines for Directory Pilots |
| |
| Authors: | P. Barker, S.E. Hardcastle-Kille. |
| Date: | January 1993 |
| Formats: | txt ps html pdf json |
| Obsoleted by: | RFC 1617, RTR_0011 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1384 |
|
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines.Alignment to these guidelines is recommended for directory pilots. |
|
| |
| RFC 1385 | EIP: The Extended Internet Protocol |
| |
|
|
EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1386 | The US Domain |
| |
| Authors: | A. Cooper, J. Postel. |
| Date: | December 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1480 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1386 |
|
This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1387 | RIP Version 2 Protocol Analysis |
| |
|
|
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. |
|
| |
| RFC 1388 | RIP Version 2 Carrying Additional Information |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security.A companion document will define the SNMP MIB objects for RIP-2 [2]. |
|
| |
| RFC 1389 | RIP Version 2 MIB Extensions |
| |
| Authors: | G. Malkin, F. Baker. |
| Date: | January 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1389 |
|
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 RIP Version 2. |
|
| |
| RFC 1391 | The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1392 | Internet Users' Glossary |
| |
| Authors: | G. Malkin, T. LaQuey Parker. |
| Date: | January 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1983 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1392 |
|
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them. |
|
| |
| RFC 1393 | Traceroute Using an IP Option |
| |
|
|
Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run.
This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. |
|
| |
| RFC 1395 | BOOTP Vendor Information Extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP). |
|
| |
| RFC 1398 | Definitions of Managed Objects for the Ethernet-Like Interface Types |
| |
|
|
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 ethernet-like objects. |
|
| |
| RFC 1404 | A Model for Common Operational Statistics |
| |
|
|
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. |
|
| |
| RFC 1405 | Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) |
| |
|
|
This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 )Recommendations on Message Handling Systems, and systems running theMail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group. |
|
| |
| RFC 1406 | Definitions of Managed Objects for the DS1 and E1 Interface Types |
| |
|
|
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 DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links.
This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1232 should not be implemented. |
|
| |
| RFC 1407 | Definitions of Managed Objects for the DS3/E3 Interface Type |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type.
This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1233 should not be implemented. |
|
| |
| RFC 1409 | Telnet Authentication Option |
| |
|
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1410 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). |
|
| |
| RFC 1416 | Telnet Authentication Option |
| |
|
|
This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1417 | NADF Standing Documents: A Brief Overview |
| |
|
|
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1425 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1651 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1425 |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1426 | SMTP Service Extension for 8bit-MIMEtransport |
| |
| Authors: | J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1652 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1426 |
|
This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex |
|
| |
| RFC 1427 | SMTP Service Extension for Message Size Declaration |
| |
| Authors: | J. Klensin, N. Freed, Ed., K. Moore. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1427 |
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] |
|
| |
| RFC 1434 | Data Link Switching: Switch-to-Switch Protocol |
| |
|
|
This RFC describes IBM's support of Data Link Switching over TCP/IP.The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com. |
|
| |
| RFC 1442 | Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1902 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1442 |
|
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK] |
|
| |
| RFC 1443 | Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1903 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1443 |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 1444 | Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1904 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1444 |
|
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] |
|
| |
| RFC 1448 | Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1905 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1448 |
|
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] |
|
| |
| RFC 1449 | Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1906 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1449 |
|
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] |
|
| |
| RFC 1450 | Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1907 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1450 |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1452 | Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1908 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1452 |
|
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK] |
|
| |
| RFC 1455 | Physical Link Security Type of Service |
| |
|
|
This RFC documents an experimental protocol providing a Type ofService (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type ofService in the Internet Protocol Suite. The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled. The purpose is protection against traffic analysis and as an additional possible level of data confidentiality. This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service. |
|
| |
| RFC 1460 | Post Office Protocol - Version 3 |
| |
|
|
This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK] |
|
| |
| RFC 1466 | Guidelines for Management of IP Address Space |
| |
|
|
This document has been reviewed by the Federal Engineering PlanningGroup (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1475 | TP/IX: The Next Internet |
| |
|
|
The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to theIESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992. |
|
| |
| RFC 1483 | Multiprotocol Encapsulation over ATM Adaptation Layer 5 |
| |
|
|
This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit. |
|
| |
| RFC 1484 | Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) |
| |
|
|
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [HK93], and it is intended that these specifications are compatible. Please send comments to the author or to the discussion group: <osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1485 | A String Representation of Distinguished Names (OSI-DS 23 (v5)) |
| |
|
|
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. Please send comments to the author or to the discussion group <osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1486 | An Experiment in Remote Printing |
| |
|
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1487 | X.500 Lightweight Directory Access Protocol |
| |
|
|
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of theDirectory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements. |
|
| |
| RFC 1488 | The X.500 String Representation of Standard Attribute Syntaxes |
| |
| Authors: | T. Howes, S. Kille, W. Yeong, C. Robbins. |
| Date: | July 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1778 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1488 |
|
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 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 1490 | Multiprotocol Interconnect over Frame Relay |
| |
|
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU.
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use. |
|
| |
| RFC 1493 | Definitions of Managed Objects for Bridges |
| |
| Authors: | E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. |
| Date: | July 1993 |
| Formats: | txt html json |
| Obsoletes: | RFC 1286 |
| Obsoleted by: | RFC 4188 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1493 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging.Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. |
|
| |
| RFC 1495 | Mapping between X.400 and RFC-822 Message Bodies |
| |
| Authors: | H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. |
| Date: | August 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2156 |
| Updates: | RFC 1327 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1495 |
|
Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK] |
|
| |
| RFC 1497 | BOOTP Vendor Information Extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP). |
|
| |
| RFC 1500 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1508 | Generic Security Service Application Program Interface |
| |
|
|
This Generic Security Service Application Program Interface (GSS-API) definition 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 definesGSS-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 |
|
| |
| RFC 1509 | Generic Security Service API : C-bindings |
| |
|
|
This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents.
The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
|
| |
| RFC 1510 | The Kerberos Network Authentication Service (V5) |
| |
|
|
This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites. |
|
| |
| RFC 1514 | Host Resources MIB |
| |
| Authors: | P. Grillo, S. Waldbusser. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1514 |
|
This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. |
|
| |
| RFC 1515 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1515 |
|
This document 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 IEEE 802.3Medium Attachment Units (MAUs). |
|
| |
| RFC 1516 | Definitions of Managed Objects for IEEE 802.3 Repeater Devices |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs." |
|
| |
| RFC 1519 | Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoletes: | RFC 1338 |
| Obsoleted by: | RFC 4632 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1519 |
|
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. |
|
| |
| 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 1522 | MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text |
| |
|
|
This memo describes an extension to the message format defined in RFC1521 [1], to allow the representation of character sets other thanASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. |
|
| |
| RFC 1523 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1528 | Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures |
| |
|
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1531 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP 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, 23], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 1532 | Clarifications and Extensions for the Bootstrap Protocol |
| |
|
|
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. |
|
| |
| RFC 1533 | 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. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options.
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 1537 | Common DNS Data File Configuration Errors |
| |
|
|
This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. |
|
| |
| RFC 1539 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1540 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1541 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP 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, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541. |
|
| |
| RFC 1543 | 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 1544 | The Content-MD5 Header Field |
| |
|
|
This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. |
|
| |
| RFC 1545 | FTP Operation Over Big Address Records (FOOBAR) |
| |
|
|
This paper describes a convention for specifying longer addresses in the PORT command. |
|
| |
| 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 1549 | PPP in HDLC Framing |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1551 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability forUnnumbered RIP links, On-demand statically routed links and client to router connectivity. |
|
| |
| RFC 1558 | A String Representation of LDAP Search Filters |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. |
|
| |
| RFC 1563 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1565 | Network Services Monitoring MIB |
| |
| Authors: | S. Kille, N. Freed. |
| Date: | January 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1565 |
|
This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK] |
|
| |
| RFC 1566 | Mail Monitoring MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK] |
|
| |
| RFC 1567 | X.500 Directory Monitoring MIB |
| |
| Authors: | G. Mansfield, S. Kille. |
| Date: | January 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2605 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1567 |
|
This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. |
|
| |
| RFC 1568 | Simple Network Paging Protocol - Version 1(b) |
| |
|
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm. One other paging firm is in the process of adopting it.
Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETFWork", below. |
|
| |
| RFC 1569 | Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures |
| |
|
|
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1573 | Evolution of the Interfaces Group of MIB-II |
| |
|
|
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 Network Interfaces. [STANARDS-TRACK] |
|
| |
| RFC 1577 | 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) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.
This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards. |
|
| |
| RFC 1578 | FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions |
| |
|
|
The goal of this FYI RFC, produced by the Internet School Networking(ISN) group in the User Services Area of the Internet EngineeringTask Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools. |
|
| |
| RFC 1583 | 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. Separate routes can be calculated for each IP Type of Service. 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.
OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in AppendixE. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 1587 | The OSPF NSSA Option |
| |
| Authors: | R. Coltun, V. Fuller. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3101 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1587 |
|
This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK] |
|
| |
| RFC 1590 | Media Type Registration Procedure |
| |
|
|
Several protocols allow the use of data representing different"media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] defined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet AssignedNumbers Authority (IANA). Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes). It also generalizes the scope of use of these MediaTypes to make it appropriate to use the same registrations and specifications with other applications. |
|
| |
| RFC 1594 | FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| RFC 1595 | Definitions of Managed Objects for the SONET/SDH Interface Type |
| |
| Authors: | T. Brown, K. Tesink. |
| Date: | March 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2558 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1595 |
|
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 Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 1596 | Definitions of Managed Objects for Frame Relay Service |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1597 | Address Allocation for Private Internets |
| |
| Authors: | Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1597 |
|
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1600 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1601 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. |
|
| |
| RFC 1602 | The Internet Standards Process -- Revision 2 |
| |
| Authors: | Internet Architecture Board, Internet Engineering Steering Group. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1602 |
|
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C. |
|
| |
| RFC 1603 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. |
|
| |
| RFC 1604 | Definitions of Managed Objects for Frame Relay Service |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1610 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1619 | PPP over SONET/SDH |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits.
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@merit.edu mailing list. |
|
| |
| RFC 1623 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1626 | Default IP MTU for use over ATM AAL5 |
| |
|
|
There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK] |
|
| |
| RFC 1627 | Network 10 Considered Harmful (Some Practices Shouldn't be Codified) |
| |
| Authors: | E. Lear, E. Fair, D. Crocker, T. Kessler. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1627 |
|
This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1631 | The IP Network Address Translator (NAT) |
| |
|
|
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons. |
|
| |
| RFC 1632 | A Revised Catalog of Available X.500 Implementations |
| |
|
|
This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.
This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 1637 | DNS NSAP Resource Records |
| |
|
|
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation. |
|
| |
| RFC 1638 | PPP Bridging Control Protocol (BCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. |
|
| |
| RFC 1642 | UTF-7 - A Mail-Safe Transformation Format of Unicode |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME". |
|
| |
| RFC 1643 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1644 | T/TCP -- TCP Extensions for Transactions Functional Specification |
| |
|
|
This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1645 | Simple Network Paging Protocol - Version 2 |
| |
|
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1647 | TN3270 Enhancements |
| |
|
|
This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1]. |
|
| |
| RFC 1650 | Definitions of Managed Objects for the Ethernet-like Interface Types 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 defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1651 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1425 |
| Obsoleted by: | RFC 1869 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1651 |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1652 | SMTP Service Extension for 8bit-MIMEtransport |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt html json |
| Obsoletes: | RFC 1426 |
| Obsoleted by: | RFC 6152 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1652 |
|
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. |
|
| |
| RFC 1653 | SMTP Service Extension for Message Size Declaration |
| |
|
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. |
|
| |
| RFC 1654 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1771 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1654 |
|
This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1655 | Application of the Border Gateway Protocol in the Internet |
| |
|
|
This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net). |
|
| |
| RFC 1656 | BGP-4 Protocol Document Roadmap and Implementation Experience |
| |
|
|
Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1657 | Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 |
| |
| Authors: | S. Willis, J. Burruss, J. Chu, Ed.. |
| Date: | July 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4273 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1657 |
|
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 the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK] |
|
| |
| RFC 1664 | Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables |
| |
| Authors: | C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2163 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1664 |
|
This memo defines how to store in the Internet Domain Name System the mapping information needed by 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. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG). |
|
| |
| RFC 1665 | Definitions of Managed Objects for SNA NAUs using SMIv2 |
| |
| Authors: | Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1665 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] |
|
| |
| RFC 1693 | An Extension to TCP : Partial Order Service |
| |
| Authors: | T. Connolly, P. Amer, P. Conrad. |
| Date: | November 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1693 |
|
This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited. |
|
| |
| RFC 1695 | Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 |
| |
| Authors: | M. Ahmed, Ed., K. Tesink, Ed.. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2515 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1695 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] |
|
| |
| RFC 1700 | Assigned Numbers |
| |
|
|
This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. |
|
| |
| RFC 1714 | Referral Whois Protocol (RWhois) |
| |
|
|
This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information. |
|
| |
| RFC 1716 | Towards Requirements for IP Routers |
| |
| Authors: | P. Almquist, F. Kastenholz. |
| Date: | November 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1812 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1716 |
|
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1717 | The PPP Multilink Protocol (MP) |
| |
| Authors: | K. Sklower, B. Lloyd, G. McGregor, D. Carr. |
| Date: | November 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1990 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1717 |
|
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols. |
|
| |
| RFC 1718 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1720 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1723 | RIP Version 2 - Carrying Additional Information |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1,2], to expand the amount of useful information carried in RIP messages and to add a measure of security.This memo obsoletes RFC 1388, which specifies an update to the"Routing Information Protocol" STD 34, RFC 1058.
The RIP-2 protocol analysis is documented in RFC 1721 [4].
The RIP-2 applicability statement is document in RFC 1722 [5].
The RIP-2 MIB description is defined in RFC 1724 [3]. This memo obsoletes RFC 1389. |
|
| |
| RFC 1725 | Post Office Protocol - Version 3 |
| |
|
|
This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK] |
|
| |
| RFC 1730 | Internet Message Access Protocol - Version 4 |
| |
|
|
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).
IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT]. |
|
| |
| RFC 1734 | POP3 AUTHentication command |
| |
|
|
This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK] |
|
| |
| 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 1739 | A Primer On Internet and TCP/IP Tools |
| |
| Authors: | G. Kessler, S. Shepard. |
| Date: | December 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2151 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1739 |
|
This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1743 | 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 1750 | Randomness Recommendations for Security |
| |
| Authors: | D. Eastlake 3rd, S. Crocker, J. Schiller. |
| Date: | December 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4086 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1750 |
|
Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications. |
|
| |
| RFC 1757 | Remote Network Monitoring Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices. |
|
| |
| RFC 1759 | Printer MIB |
| |
| Authors: | R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. |
| Date: | March 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3805 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1759 |
|
A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK] |
|
| |
| RFC 1766 | Tags for the Identification of Languages |
| |
|
|
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header. |
|
| |
| RFC 1769 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Distribution of this memorandum is unlimited. |
|
| |
| RFC 1770 | IPv4 Option for Sender Directed Multi-Destination Delivery |
| |
|
|
This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed BroadcastMode (SDBM). The SDBM provides unreliable UDP delivery to a set ofIP addresses included in the option field of an IPv4 datagram. Data reliability if required will be provided by the application layer.This approach was developed to support sender directed multi- destination delivery to sparsely populated groups with no additional control traffic. This approach will find application in the extremely bandwidth constrained tactical military environment, as well as in some commercial applications requiring sender control of data delivery. |
|
| |
| RFC 1771 | A Border Gateway Protocol 4 (BGP-4) |
| |
|
|
This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet. |
|
| |
| RFC 1777 | Lightweight Directory Access Protocol |
| |
|
|
The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements. |
|
| |
| RFC 1778 | The String Representation of Standard Attribute Syntaxes |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. |
|
| |
| RFC 1779 | A String Representation of Distinguished Names |
| |
|
|
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. |
|
| |
| RFC 1780 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1781 | Using the OSI Directory to Achieve User Friendly Naming |
| |
|
|
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them.This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible. |
|
| |
| RFC 1782 | TFTP Option Extension |
| |
|
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. |
|
| |
| RFC 1783 | TFTP Blocksize Option |
| |
|
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater.
This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2]. |
|
| |
| RFC 1784 | TFTP Timeout Interval and Transfer Size Options |
| |
|
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. |
|
| |
| RFC 1788 | ICMP Domain Name Messages |
| |
|
|
This document specifies ICMP messages for learning the FullyQualified Domain Name associated with an IP address. |
|
| |
| RFC 1798 | Connection-less Lightweight X.500 Directory Access Protocol |
| |
|
|
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK] |
|
| |
| RFC 1800 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1806 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header |
| |
|
|
This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header 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 [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. |
|
| |
| 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 1811 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | June 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1816 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1811 |
|
This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1816 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | August 1995 |
| Formats: | txt html json |
| Obsoletes: | RFC 1811 |
| Obsoleted by: | RFC 2146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1816 |
|
This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1820 | Multimedia E-mail (MIME) User Agent Checklist |
| |
|
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1825 | Security Architecture for the Internet Protocol |
| |
|
|
This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK] |
|
| |
| RFC 1826 | IP Authentication Header |
| |
|
|
This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1827 | IP Encapsulating Security Payload (ESP) |
| |
|
|
This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1830 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages |
| |
|
|
This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1831 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
|
|
This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1832 | XDR: External Data Representation Standard |
| |
|
|
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1836 | Representing the O/R Address hierarchy in the X.500 Directory Information Tree |
| |
|
|
This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: |
|
| |
| RFC 1837 | Representing Tables and Subtrees in the X.500 Directory |
| |
|
|
This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability. |
|
| |
| RFC 1838 | Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses |
| |
|
|
This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. |
|
| |
| RFC 1849 | "Son of 1036": News Article Format and Transmission |
| |
|
|
By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adoptedProposed Standards for Netnews.
It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. |
|
| |
| RFC 1850 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Open Shortest PathFirst Routing Protocol. |
|
| |
| RFC 1852 | IP Authentication using Keyed SHA |
| |
| Authors: | P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2841 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1852 |
|
This document describes the use of keyed SHA with the IPAuthentication Header. |
|
| |
| RFC 1854 | SMTP Service Extension for Command Pipelining |
| |
|
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. |
|
| |
| RFC 1860 | Variable Length Subnet Table For IPv4 |
| |
| Authors: | T. Pummill, B. Manning. |
| Date: | October 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1878 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1860 |
|
This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE). |
|
| |
| RFC 1863 | A BGP/IDRP Route Server alternative to a full mesh routing |
| |
|
|
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud). |
|
| |
| RFC 1866 | Hypertext Markup Language - 2.0 |
| |
| Authors: | T. Berners-Lee, D. Connolly. |
| Date: | November 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1866 |
|
The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text andOffice Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type(RFC 1521) is defined by this specification. |
|
| |
| RFC 1867 | Form-based File Upload in HTML |
| |
|
|
Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1869 | SMTP Service Extensions |
| |
|
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1871 | Addendum to RFC 1602 -- Variance Procedure |
| |
|
|
This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This is a modification to the procedures of RFC 1602 and 1603. |
|
| |
| RFC 1872 | The MIME Multipart/Related Content-type |
| |
|
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 1880 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1883 | Internet Protocol, Version 6 (IPv6) Specification |
| |
| Authors: | S. Deering, R. Hinden. |
| Date: | December 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1883 |
|
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. |
|
| |
| RFC 1884 | IP Version 6 Addressing Architecture |
| |
| Authors: | R. Hinden, Ed., S. Deering, Ed.. |
| Date: | December 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2373 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1884 |
|
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 nodes required addresses. |
|
| |
| RFC 1885 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
| |
| Authors: | A. Conta, S. Deering. |
| Date: | December 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2463 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1885 |
|
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document. |
|
| |
| RFC 1886 | DNS Extensions to support IP version 6 |
| |
|
|
This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. |
|
| |
| RFC 1888 | OSI NSAPs and IPv6 |
| |
| Authors: | J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. |
| Date: | August 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4048 |
| Updated by: | RFC 4548 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1888 |
|
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. |
|
| |
| RFC 1889 | RTP: A Transport Protocol for Real-Time Applications |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1889 |
|
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. |
|
| |
| RFC 1890 | RTP Profile for Audio and Video Conferences with Minimal Control |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3551 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1890 |
|
This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. |
|
| |
| RFC 1891 | SMTP Service Extension for Delivery Status Notifications |
| |
|
|
This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] |
|
| |
| RFC 1892 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK] |
|
| |
| RFC 1893 | Enhanced Mail System Status Codes |
| |
|
|
There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK] |
|
| |
| RFC 1894 | An Extensible Message Format for Delivery Status Notifications |
| |
|
|
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.
Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.
NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change. |
|
| |
| RFC 1897 | IPv6 Testing Address Allocation |
| |
|
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. |
|
| |
| RFC 1902 | Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1442 |
| Obsoleted by: | RFC 2578 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1902 |
|
It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] |
|
| |
| RFC 1903 | Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1443 |
| Obsoleted by: | RFC 2579 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1903 |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 1904 | Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1444 |
| Obsoleted by: | RFC 2580 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1904 |
|
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] |
|
| |
| RFC 1905 | Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1448 |
| Obsoleted by: | RFC 3416 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1905 |
|
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] |
|
| |
| RFC 1906 | Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1449 |
| Obsoleted by: | RFC 3417 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1906 |
|
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] |
|
| |
| RFC 1907 | Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1450 |
| Obsoleted by: | RFC 3418 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1907 |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1908 | Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1452 |
| Obsoleted by: | RFC 2576 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1908 |
|
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK] |
|
| |
| RFC 1911 | Voice Profile for Internet Mail |
| |
|
|
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1920 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1933 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
| Authors: | R. Gilligan, E. Nordmark. |
| Date: | April 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1933 |
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. |
|
| |
| RFC 1938 | A One-Time Password System |
| |
|
|
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK] |
|
| |
| RFC 1942 | HTML Tables |
| |
|
|
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context. |
|
| |
| RFC 1944 | Benchmarking Methodology for Network Interconnect Devices |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 1948 | Defending Against Sequence Number Attacks |
| |
|
|
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. |
|
| |
| RFC 1959 | An LDAP URL Format |
| |
|
|
This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1960 | A String Representation of LDAP Search Filters |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 1965 | Autonomous System Confederations for BGP |
| |
|
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.
The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
The extension this document describes is widely deployed in theInternet today. |
|
| |
| RFC 1966 | BGP Route Reflection An alternative to full mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 1969 | The PPP DES Encryption Protocol (DESE) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. |
|
| |
| RFC 1970 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2461 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1970 |
|
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 1971 | IPv6 Stateless Address Autoconfiguration |
| |
| Authors: | S. Thomson, T. Narten. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1971 |
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. |
|
| |
| RFC 1972 | A Method for the Transmission of IPv6 Packets over Ethernet Networks |
| |
|
|
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK] |
|
| |
| RFC 1980 | A Proposed Extension to HTML : Client-Side Image Maps |
| |
|
|
The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations. |
|
| |
| RFC 1981 | Path MTU Discovery for IP version 6 |
| |
| Authors: | J. McCann, S. Deering, J. Mogul. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8201 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1981 |
|
This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery forIP version 4. |
|
| |
| RFC 1991 | PGP Message Exchange Formats |
| |
| Authors: | D. Atkins, W. Stallings, P. Zimmermann. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4880 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1991 |
|
This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2000 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. |
|
| |
| RFC 2001 | TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms |
| |
|
|
Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet. |
|
| |
| RFC 2002 | IP Mobility Support |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 2010 | Operational Criteria for Root Name Servers |
| |
|
|
This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. |
|
| |
| RFC 2011 | SNMPv2 Management Information Base for the Internet Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK] |
|
| |
| RFC 2012 | SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK] |
|
| |
| RFC 2013 | SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK] |
|
| |
| RFC 2019 | Transmission of IPv6 Packets Over FDDI |
| |
|
|
This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK] |
|
| |
| RFC 2021 | Remote Network Monitoring Management Information Base Version 2 using SMIv2 |
| |
|
|
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. |
|
| |
| RFC 2023 | IP Version 6 over PPP |
| |
| Authors: | D. Haskin, E. Allen. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2023 |
|
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 method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. |
|
| |
| RFC 2027 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today. |
|
| |
| 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 2030 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 2031 | IETF-ISOC relationship |
| |
|
|
This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. |
|
| |
| RFC 2032 | RTP Payload Format for H.261 Video Streams |
| |
| Authors: | T. Turletti, C. Huitema. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4587 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2032 |
|
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK] |
|
| |
| RFC 2035 | RTP Payload Format for JPEG-compressed Video |
| |
| Authors: | L. Berc, W. Fenner, R. Frederick, S. McCanne. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2435 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2035 |
|
This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame.
This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s). |
|
| |
| RFC 2037 | Entity MIB using SMIv2 |
| |
| Authors: | K. McCloghrie, A. Bierman. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2037 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK] |
|
| |
| RFC 2038 | RTP Payload Format for MPEG1/MPEG2 Video |
| |
| Authors: | D. Hoffman, G. Fernando, V. Goyal. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2250 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2038 |
|
This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. |
|
| |
| RFC 2044 | UTF-8, a transformation format of Unicode and ISO 10646 |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. |
|
| |
| 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 2050 | Internet Registry IP Allocation Guidelines |
| |
| Authors: | K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. |
| Date: | November 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1466 |
| Obsoleted by: | RFC 7020 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2050 |
|
This document describes the registry system for the distribution of globally unique Internet address space and registry operations.Particularly this document describes the rules and guidelines governing the distribution of this address space.
This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by theIANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.
This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience.
This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate. |
|
| |
| RFC 2052 | A DNS RR for specifying the location of services (DNS SRV) |
| |
| Authors: | A. Gulbrandsen, P. Vixie. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2782 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2052 |
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). |
|
| |
| RFC 2058 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2138 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2058 |
|
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 2059 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2060 | Internet Message Access Protocol - Version 4rev1 |
| |
|
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. |
|
| |
| RFC 2063 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2722 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2063 |
|
This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group. |
|
| |
| RFC 2064 | Traffic Flow Measurement: Meter MIB |
| |
|
|
This memo defines a 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 obtaining traffic flow information from network traffic meters. |
|
| |
| RFC 2065 | Domain Name System Security Extensions |
| |
|
|
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service 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. |
|
| |
| RFC 2068 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2616 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2068 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.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". |
|
| |
| RFC 2069 | An Extension to HTTP : Digest Access Authentication |
| |
| Authors: | J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2617 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2069 |
|
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic,Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2070 | Internationalization of the Hypertext Markup Language |
| |
| Authors: | F. Yergeau, G. Nicol, G. Adams, M. Duerst. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2070 |
|
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world. |
|
| |
| RFC 2073 | An IPv6 Provider-Based Unicast Address Format |
| |
| Authors: | Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2374 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2073 |
|
This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2074 | Remote Network Monitoring MIB Protocol Identifiers |
| |
| Authors: | A. Bierman, R. Iddon. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2074 |
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK] |
|
| |
| RFC 2078 | Generic Security Service Application Program Interface, Version 2 |
| |
|
|
The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, 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 definesGSS-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 revises RFC-1508, 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 2082 | RIP-2 MD5 Authentication |
| |
| Authors: | F. Baker, R. Atkinson. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4822 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2082 |
|
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2086 | IMAP4 ACL extension |
| |
|
|
The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2087 | IMAP4 QUOTA extension |
| |
|
|
The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2088 | IMAP4 non-synchronizing literals |
| |
|
|
The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK] |
|
| |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent |
| |
|
|
The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). |
|
| |
| RFC 2095 | IMAP/POP AUTHorize Extension for Simple Challenge/Response |
| |
| Authors: | J. Klensin, R. Catoe, P. Krumviede. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2195 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2095 |
|
While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. |
|
| |
| RFC 2096 | IP Forwarding Table MIB |
| |
|
|
This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK] |
|
| |
| RFC 2106 | Data Link Switching Remote Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2114 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2106 |
|
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com. |
|
| |
| RFC 2109 | HTTP State Management Mechanism |
| |
|
|
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK] |
|
| |
| RFC 2110 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| |
| Authors: | J. Palme, A. Hopmann. |
| Date: | March 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2557 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2110 |
|
Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base". |
|
| |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators |
| |
|
|
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. |
|
| |
| RFC 2112 | The MIME Multipart/Related Content-type |
| |
|
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 2117 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2362 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2117 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2133 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | April 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2553 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2133 |
|
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 [5]. |
|
| |
| RFC 2137 | Secure Domain Name System Dynamic Update |
| |
|
|
Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. |
|
| |
| RFC 2138 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | April 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 2058 |
| Obsoleted by: | RFC 2865 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2138 |
|
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 2139 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2140 | TCP Control Block Interdependence |
| |
|
|
This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI. |
|
| |
| RFC 2141 | URN Syntax |
| |
|
|
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. |
|
| |
| RFC 2145 | Use and Interpretation of HTTP Version Numbers |
| |
| Authors: | J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. |
| Date: | May 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7230 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2145 |
|
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP. |
|
| |
| RFC 2147 | TCP and UDP over IPv6 Jumbograms |
| |
|
|
IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK] |
|
| |
| RFC 2155 | Definitions of Managed Objects for APPN using SMIv2 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | June 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2455 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2155 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] |
|
| |
| 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 2178 | 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 1583 are explained inAppendix G. All differences are backward-compatible in nature.Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2184 | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations |
| |
|
|
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK] |
|
| |
| RFC 2192 | IMAP URL Scheme |
| |
|
|
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server. |
|
| |
| RFC 2197 | SMTP Service Extension for Command Pipelining |
| |
|
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK] |
|
| |
| RFC 2200 | Internet Official Protocol Standards |
| |
|
|
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] |
|
| |
| RFC 2204 | ODETTE File Transfer Protocol |
| |
|
|
This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.
The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. |
|
| |
| 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 2233 | The Interfaces Group 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 Network Interfaces. [STANDARDS-TRACK] |
|
| |
| RFC 2234 | Augmented BNF for Syntax Specifications: ABNF |
| |
| Authors: | D. Crocker, Ed., P. Overell. |
| Date: | November 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4234 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2234 |
|
In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK] |
|
| |
| RFC 2239 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 |
| |
| Authors: | K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | November 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2668 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2239 |
|
This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing 10 and 100 Mb/secondMedium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,"10 & 100 Mb/s Management," October 26, 1995. |
|
| |
| RFC 2240 | A Legal Basis for Domain Name Allocation |
| |
|
|
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2245 | Anonymous SASL Mechanism |
| |
|
|
It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. |
|
| |
| 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 2248 | Network Services Monitoring MIB |
| |
|
|
This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK] |
|
| |
| RFC 2249 | Mail Monitoring MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [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 2257 | Agent Extensibility (AgentX) Protocol Version 1 |
| |
| Authors: | M. Daniele, B. Wijnen, D. Francisco. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2741 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2257 |
|
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK] |
|
| |
| RFC 2261 | An Architecture for Describing SNMP Management Frameworks |
| |
| Authors: | D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2261 |
|
This document describes an architecture for describing SNMPManagement 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 an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2262 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2262 |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2263 | SNMPv3 Applications |
| |
| Authors: | D. Levi, P. Meyer, B. Stewart. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2273 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2263 |
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2264 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
| Authors: | U. Blumenthal, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2264 |
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2265 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | B. Wijnen, R. Presuhn, K. McCloghrie. |
| Date: | January 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2265 |
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2267 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
| Authors: | P. Ferguson, D. Senie. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2827 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2267 |
|
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 2271 | An Architecture for Describing SNMP Management Frameworks |
| |
|
|
This document describes an architecture for describing SNMPManagement 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 an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2272 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoletes: | RFC 2262 |
| Obsoleted by: | RFC 2572 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2272 |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2273 | SNMPv3 Applications |
| |
|
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2274 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
|
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2275 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2278 | IANA Charset Registration Procedures |
| |
|
|
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2279 | UTF-8, a transformation format of ISO 10646 |
| |
|
|
ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. |
|
| |
| RFC 2280 | Routing Policy Specification Language (RPSL) |
| |
| Authors: | C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. |
| Date: | January 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2280 |
|
This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous 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. [STANDARDS-TRACK] |
|
| |
| RFC 2282 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2283 | Multiprotocol Extensions for BGP-4 |
| |
| Authors: | T. Bates, R. Chandra, D. Katz, Y. Rekhter. |
| Date: | February 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2858 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2283 |
|
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] |
|
| |
| RFC 2284 | PPP Extensible Authentication Protocol (EAP) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines the PPP Extensible Authentication Protocol. |
|
| |
| RFC 2292 | Advanced Sockets API for IPv6 |
| |
| Authors: | W. Stevens, M. Thomas. |
| Date: | February 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3542 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2292 |
|
Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.
But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.
There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. |
|
| |
| RFC 2298 | An Extensible Message Format for Message Disposition Notifications |
| |
|
|
This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
|
| |
| RFC 2300 | Internet Official Protocol Standards |
| |
|
|
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] |
|
| |
| RFC 2301 | File Format for Internet Fax |
| |
| Authors: | L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. |
| Date: | March 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2301 |
|
This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. Files formatted according to this specification use the image/tiff MIME Content Type. |
|
| |
| RFC 2302 | Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration |
| |
| Authors: | G. Parsons, J. Rafferty, S. Zilles. |
| Date: | March 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3302 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2302 |
|
This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK] |
|
| |
| RFC 2303 | Minimal PSTN address format in Internet Mail |
| |
|
|
This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK] |
|
| |
| RFC 2304 | Minimal FAX address format in Internet Mail |
| |
|
|
This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK] |
|
| |
| RFC 2305 | A Simple Mode of Facsimile Using Internet Mail |
| |
| Authors: | K. Toyoda, H. Ohno, J. Murai, D. Wing. |
| Date: | March 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3965 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2305 |
|
This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2309 | Recommendations on Queue Management and Congestion Avoidance in the Internet |
| |
| Authors: | B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7567 |
| Updated by: | RFC 7141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2309 |
|
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. |
|
| |
| RFC 2313 | PKCS #1: RSA Encryption Version 1.5 |
| |
|
|
This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2314 | PKCS #10: Certification Request Syntax Version 1.5 |
| |
|
|
This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2326 | Real Time Streaming Protocol (RTSP) |
| |
| Authors: | H. Schulzrinne, A. Rao, R. Lanphier. |
| Date: | April 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7826 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2326 |
|
The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). |
|
| |
| RFC 2327 | SDP: Session Description Protocol |
| |
|
|
This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. |
|
| |
| RFC 2338 | Virtual Router Redundancy Protocol |
| |
| Authors: | S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3768 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2338 |
|
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
|
| |
| RFC 2344 | Reverse Tunneling for Mobile IP |
| |
|
|
Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address.When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. |
|
| |
| RFC 2358 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2359 | IMAP4 UIDPLUS extension |
| |
|
|
The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK] |
|
| |
| RFC 2362 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2117 |
| Obsoleted by: | RFC 4601, RFC 5059 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2362 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2366 | Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community. |
|
| |
| RFC 2368 | The mailto URL scheme |
| |
|
|
This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields. |
|
| |
| 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 2373 | IP Version 6 Addressing Architecture |
| |
|
|
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses. |
|
| |
| RFC 2374 | An IPv6 Aggregatable Global Unicast Address Format |
| |
|
|
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2376 | XML Media Types |
| |
|
|
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the WorldWide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. |
|
| |
| RFC 2385 | Protection of BGP Sessions via the TCP MD5 Signature Option |
| |
|
|
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. |
|
| |
| RFC 2388 | Returning Values from Forms: multipart/form-data |
| |
|
|
This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK] |
|
| |
| RFC 2393 | IP Payload Compression Protocol (IPComp) |
| |
| Authors: | A. Shacham, R. Monsour, R. Pereira, M. Thomas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2393 |
|
This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. |
|
| |
| 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 2400 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK] |
|
| |
| RFC 2401 | Security Architecture for the Internet Protocol |
| |
|
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2402 | IP Authentication Header |
| |
|
|
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK] |
|
| |
| RFC 2406 | IP Encapsulating Security Payload (ESP) |
| |
|
|
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK] |
|
| |
| RFC 2407 | The Internet IP Security Domain of Interpretation for ISAKMP |
| |
|
|
This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK] |
|
| |
| RFC 2408 | Internet Security Association and Key Management Protocol (ISAKMP) |
| |
| Authors: | D. Maughan, M. Schertler, M. Schneider, J. Turner. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4306 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2408 |
|
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment. |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
|
|
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] |
|
| |
| RFC 2411 | IP Security Document Roadmap |
| |
| Authors: | R. Thayer, N. Doraswamy, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6071 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2411 |
|
The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and AuthenticationAlgorithm documents are described. |
|
| |
| RFC 2413 | Dublin Core Metadata for Resource Discovery |
| |
| Authors: | S. Weibel, J. Kunze, C. Lagoze, M. Wolf. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5013 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2413 |
|
This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community. |
|
| |
| RFC 2414 | Increasing TCP's Initial Window |
| |
| Authors: | M. Allman, S. Floyd, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3390 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2414 |
|
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP. |
|
| |
| RFC 2421 | Voice Profile for Internet Mail - version 2 |
| |
|
|
This document profiles Internet mail for voice messaging. [STANDARDS- TRACK] |
|
| |
| RFC 2422 | Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration |
| |
|
|
This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK] |
|
| |
| RFC 2423 | VPIM Voice Message MIME Sub-type Registration |
| |
|
|
This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK] |
|
| |
| RFC 2424 | Content Duration MIME Header Definition |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3803 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2424 |
|
This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK] |
|
| |
| RFC 2425 | A MIME Content-Type for Directory Information |
| |
| Authors: | T. Howes, M. Smith, F. Dawson. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2425 |
|
This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK] |
|
| |
| RFC 2426 | vCard MIME Directory Profile |
| |
| Authors: | F. Dawson, T. Howes. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2426 |
|
This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document. |
|
| |
| RFC 2429 | RTP Payload Format for the 1998 Version of ITU-T Rec |
| |
| Authors: | H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. |
| Date: | October 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4629 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2429 |
|
This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK] |
|
| |
| RFC 2434 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. |
|
| |
| RFC 2436 | Collaboration between ISOC/IETF and ITU-T |
| |
| Authors: | R. Brett, S. Bradner, G. Parsons. |
| Date: | October 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3356 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2436 |
|
This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community. |
|
| |
| RFC 2437 | PKCS #1: RSA Cryptography Specifications Version 2.0 |
| |
|
|
This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community. |
|
| |
| RFC 2440 | OpenPGP Message Format |
| |
| Authors: | J. Callas, L. Donnerhacke, H. Finney, R. Thayer. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2440 |
|
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP. |
|
| |
| RFC 2445 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
| Authors: | F. Dawson, D. Stenerson. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5545 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2445 |
|
There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across theInternet.
This memo is formatted as a registration for a MIME media type per[RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type.
The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification.
This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol. |
|
| |
| RFC 2446 | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
| |
| Authors: | S. Silverberg, S. Mansour, F. Dawson, R. Hopson. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5546 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2446 |
|
This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems.Subsequent documents specify interoperable methods of communications between systems that use this protocol.
The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects.Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects.
This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol(iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols. |
|
| |
| RFC 2447 | iCalendar Message-Based Interoperability Protocol (iMIP) |
| |
| Authors: | F. Dawson, S. Mansour, S. Silverberg. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6047 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2447 |
|
This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject Model [iCAL] are composed using constructs from [RFC-822],[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
This document is based on discussions within the Internet EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. |
|
| |
| RFC 2452 | IP Version 6 Management Information Base for the Transmission Control Protocol |
| |
|
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2454 | IP Version 6 Management Information Base for the User Datagram Protocol |
| |
|
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the UserDatagram Protocol (UDP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of whichIP versions underlie UDP, and only the UDP listener information is IP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2459 | Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
| |
| Authors: | R. Housley, W. Ford, W. Polk, D. Solo. |
| Date: | January 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2459 |
|
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the 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 (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices. |
|
| |
| RFC 2460 | Internet Protocol, Version 6 (IPv6) Specification |
| |
|
|
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. |
|
| |
| RFC 2461 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
|
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 2462 | IPv6 Stateless Address Autoconfiguration |
| |
|
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. |
|
| |
| RFC 2463 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
|
|
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). |
|
| |
| RFC 2465 | Management Information Base for IP Version 6: Textual Conventions and General Group |
| |
|
|
This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions. |
|
| |
| RFC 2466 | Management Information Base for IP Version 6: ICMPv6 Group |
| |
|
|
This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions. |
|
| |
| RFC 2471 | IPv6 Testing Address Allocation |
| |
|
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2472 | IP Version 6 over PPP |
| |
|
|
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 method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. |
|
| |
| RFC 2476 | Message Submission |
| |
| Authors: | R. Gellens, J. Klensin. |
| Date: | December 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4409 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2476 |
|
This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK] |
|
| |
| RFC 2478 | The Simple and Protected GSS-API Negotiation Mechanism |
| |
| Authors: | E. Baize, D. Pinkas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4178 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2478 |
|
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK] |
|
| |
| RFC 2481 | A Proposal to add Explicit Congestion Notification (ECN) to IP |
| |
| Authors: | K. Ramakrishnan, S. Floyd. |
| Date: | January 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3168 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2481 |
|
This note describes a proposed addition of ECN (Explicit CongestionNotification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a CongestionExperienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols(e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. |
|
| |
| RFC 2482 | Language Tagging in Unicode Plain Text |
| |
|
|
This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community. |
|
| |
| RFC 2486 | The Network Access Identifier |
| |
| Authors: | B. Aboba, M. Beadles. |
| Date: | January 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4282 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2486 |
|
This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2487 | SMTP Service Extension for Secure SMTP over TLS |
| |
|
|
This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK] |
|
| |
| RFC 2489 | Procedure for Defining New DHCP Options |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) 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."
New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. |
|
| |
| RFC 2493 | Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals |
| |
|
|
This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. |
|
| |
| RFC 2495 | Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document withDefinitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 2496 | Definitions of Managed Object for the DS3/E3 Interface Type |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC2495 [17]), and the work in progress SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 2498 | IPPM Metrics for Measuring Connectivity |
| |
|
|
This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2500 | Internet Official Protocol Standards |
| |
|
|
This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK] |
|
| |
| RFC 2509 | IP Header Compression over PPP |
| |
| Authors: | M. Engan, S. Casner, C. Bormann. |
| Date: | February 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3544 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2509 |
|
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. |
|
| |
| RFC 2510 | Internet X.509 Public Key Infrastructure Certificate Management Protocols |
| |
| Authors: | C. Adams, S. Farrell. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2510 |
|
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.Note that "certificate" in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM]. |
|
| |
| RFC 2511 | Internet X.509 Certificate Request Message Format |
| |
| Authors: | M. Myers, C. Adams, D. Solo, D. Kemp. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4211 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2511 |
|
This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK] |
|
| |
| RFC 2518 | HTTP Extensions for Distributed Authoring -- WEBDAV |
| |
| Authors: | Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. |
| Date: | February 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4918 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2518 |
|
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). |
|
| |
| RFC 2527 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| |
|
|
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. |
|
| |
| RFC 2531 | Content Feature Schema for Internet Fax |
| |
| Authors: | G. Klyne, L. McIntyre. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2879 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2531 |
|
This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5].
This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information. |
|
| |
| RFC 2535 | Domain Name System Security Extensions |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2065 |
| Obsoleted by: | RFC 4033, RFC 4034, RFC 4035 |
| Updates: | RFC 2181, RFC 1035, RFC 1034 |
| Updated by: | RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2535 |
|
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.
The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.
This document incorporates feedback on RFC 2065 from early implementers and potential users. |
|
| |
| RFC 2537 | RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) |
| |
|
|
A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records. |
|
| |
| RFC 2538 | Storing Certificates in the Domain Name System (DNS) |
| |
| Authors: | D. Eastlake 3rd, O. Gudmundsson. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2538 |
|
Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). |
|
| |
| RFC 2541 | DNS Security Operational Considerations |
| |
|
|
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. |
|
| |
| RFC 2543 | SIP: Session Initiation Protocol |
| |
|
|
The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. |
|
| |
| RFC 2546 | 6Bone Routing Practice |
| |
|
|
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community. |
|
| |
| RFC 2547 | BGP/MPLS VPNs |
| |
|
|
This document describes a method by which a Service Provider with anIP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border GatewayProtocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers. |
|
| |
| RFC 2553 | Basic Socket Interface Extensions for IPv6 |
| |
|
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. |
|
| |
| RFC 2554 | SMTP Service Extension for Authentication |
| |
|
|
This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK] |
|
| |
| RFC 2558 | Definitions of Managed Objects for the SONET/SDH Interface Type |
| |
|
|
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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK] |
|
| |
| RFC 2559 | Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
| |
|
|
Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK] |
|
| |
| RFC 2560 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
| Authors: | M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6960 |
| Updated by: | RFC 6277 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2560 |
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK] |
|
| |
| RFC 2565 | Internet Printing Protocol/1.0: Encoding and Transport |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2910 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2565 |
|
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 HTTP a message body whose Content-Type is "application/ipp".
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: 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.0. Operator and administrator requirements are out of scope for version 1.0.
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 specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: 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.
This document "Internet Printing Protocol/1.0: 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 2566 | Internet Printing Protocol/1.0: Model and Semantics |
| |
| Authors: | R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. |
| Date: | April 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2911 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2566 |
|
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.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs.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.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: 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. Operator and administrator requirements are out of scope for version 1.0.
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 specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: 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.0 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 2570 | Introduction to Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3410 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2570 |
|
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time. |
|
| |
| RFC 2571 | An Architecture for Describing SNMP Management Frameworks |
| |
|
|
This document describes an architecture for describing SNMPManagement 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 an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2572 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | April 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2272 |
| Obsoleted by: | RFC 3412 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2572 |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2571]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2573 | SNMP Applications |
| |
|
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2571]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2574 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
|
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2575 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2571]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2576 | Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework |
| |
|
|
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14]. |
|
| |
| RFC 2581 | TCP Congestion Control |
| |
|
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. |
|
| |
| RFC 2582 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
|
|
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. |
|
| |
| RFC 2587 | Internet X.509 Public Key Infrastructure LDAPv2 Schema |
| |
| Authors: | S. Boeyen, T. Howes, P. Richard. |
| Date: | June 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4523 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2587 |
|
The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK] |
|
| |
| RFC 2591 | Definitions of Managed Objects for Scheduling Management Operations |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3231 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2591 |
|
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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. |
|
| |
| RFC 2592 | Definitions of Managed Objects for the Delegation of Management Script |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3165 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2592 |
|
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 a set of managed objects that allow the delegation of management scripts to distributed managers. |
|
| |
| RFC 2593 | Script MIB Extensibility Protocol Version 1.0 |
| |
| Authors: | J. Schoenwaelder, J. Quittek. |
| Date: | May 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3179 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2593 |
|
The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. |
|
| |
| RFC 2596 | Use of Language Codes in LDAP |
| |
|
|
This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK] |
|
| |
| RFC 2598 | An Expedited Forwarding PHB |
| |
| Authors: | V. Jacobson, K. Nichols, K. Poduri. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2598 |
|
The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.
A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf |
|
| |
| RFC 2600 | Internet Official Protocol Standards |
| |
|
|
This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK] |
|
| |
| RFC 2604 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
|
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2611 | URN Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2611 |
|
The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". |
|
| |
| RFC 2616 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. |
| Date: | June 1999 |
| Formats: | txt ps html pdf json |
| Obsoletes: | RFC 2068 |
| Obsoleted by: | RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 |
| Updated by: | RFC 2817, RFC 5785, RFC 6266, RFC 6585 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2616 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. |
|
| |
| RFC 2617 | HTTP Authentication: Basic and Digest Access Authentication |
| |
|
|
"HTTP/1.0", includes the specification for a Basic AccessAuthentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "DigestAccess Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified byRFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2618 | RADIUS Authentication Client MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. |
|
| |
| RFC 2619 | RADIUS Authentication Server MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. |
|
| |
| RFC 2620 | RADIUS Accounting Client MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. |
|
| |
| RFC 2621 | RADIUS Accounting Server MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. |
|
| |
| RFC 2625 | IP and ARP over Fibre Channel |
| |
| Authors: | M. Rajagopal, R. Bhagwat, W. Rickard. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2625 |
|
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. |
|
| |
| RFC 2629 | Writing I-Ds and RFCs using XML |
| |
|
|
This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series. |
|
| |
| RFC 2630 | Cryptographic Message Syntax |
| |
|
|
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management. |
|
| |
| RFC 2632 | S/MIME Version 3 Certificate Handling |
| |
|
|
S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK] |
|
| |
| RFC 2633 | S/MIME Version 3 Message Specification |
| |
|
|
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] |
|
| |
| RFC 2639 | Internet Printing Protocol/1.0: Implementer's Guide |
| |
|
|
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 contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 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 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.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]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. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
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 specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2646 | The Text/Plain Format Parameter |
| |
|
|
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK] |
|
| |
| RFC 2665 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2667 | IP Tunnel MIB |
| |
|
|
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK] |
|
| |
| RFC 2668 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | August 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2239 |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2668 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2669 | DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2670 | Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2671 | Extension Mechanisms for DNS (EDNS0) |
| |
|
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. |
|
| |
| RFC 2672 | Non-Terminal DNS Name Redirection |
| |
|
|
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK] |
|
| |
| RFC 2673 | Binary Labels in the Domain Name System |
| |
|
|
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK] |
|
| |
| RFC 2674 | Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions |
| |
| Authors: | E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. |
| Date: | August 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4363 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2674 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB]. |
|
| |
| RFC 2679 | A One-way Delay Metric for IPPM |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7679 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2679 |
|
This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK] |
|
| |
| RFC 2680 | A One-way Packet Loss Metric for IPPM |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7680 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2680 |
|
This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK] |
|
| |
| RFC 2700 | Internet Official Protocol Standards |
| |
|
|
This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering TaskForce (IETF). Sections 3.1 - 3.6 contain the lists of protocols in each stage of standardization - Standard, Draft Standard, ProposedStandard, Experimental and Historic. Protocols that are new to this document or have been moved from one protocol level to another, or differ from the previous edition of this document are marked.Informational Request for Comments (RFCs) are not included. This memo lists the current protocols; it is not a complete index to RFCs. |
|
| |
| RFC 2705 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. |
| Date: | October 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2705 |
|
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
|
| |
| RFC 2706 | ECML v1: Field Names for E-Commerce |
| |
| Authors: | D. Eastlake 3rd, T. Goldstein. |
| Date: | October 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3106 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2706 |
|
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. |
|
| |
| RFC 2716 | PPP EAP TLS Authentication Protocol |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2717 | Registration Procedures for URL Scheme Names |
| |
| Authors: | R. Petke, I. King. |
| Date: | November 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4395 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2717 |
|
This document defines the process by which new URL scheme names are registered. |
|
| |
| RFC 2718 | Guidelines for new URL Schemes |
| |
| Authors: | L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. |
| Date: | November 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4395 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2718 |
|
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes. |
|
| |
| RFC 2727 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 2731 | Encoding Dublin Core Metadata in HTML |
| |
|
|
The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community. |
|
| |
| RFC 2732 | Format for Literal IPv6 Addresses in URL's |
| |
|
|
This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol.
This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose. |
|
| |
| RFC 2733 | An RTP Payload Format for Generic Forward Error Correction |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | December 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2733 |
|
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. |
|
| |
| RFC 2737 | Entity MIB (Version 2) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. |
|
| |
| RFC 2740 | OSPF for IPv6 |
| |
| Authors: | R. Coltun, D. Ferguson, J. Moy. |
| Date: | December 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5340 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2740 |
|
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6. |
|
| |
| RFC 2751 | Signaled Preemption Priority Policy Element |
| |
|
|
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]).
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. |
|
| |
| RFC 2752 | Identity Representation for RSVP |
| |
| Authors: | S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. |
| Date: | January 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2752 |
|
This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. |
|
| |
| RFC 2754 | RPS IANA Issues |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, R. Govindan. |
| Date: | January 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6254 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2754 |
|
RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required fromIANA. |
|
| |
| RFC 2763 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
|
|
Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. |
|
| |
| RFC 2765 | Stateless IP/ICMP Translation Algorithm (SIIT) |
| |
|
|
This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. |
|
| |
| RFC 2766 | Network Address Translation - Protocol Translation (NAT-PT) |
| |
|
|
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT]. |
|
| |
| RFC 2767 | Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) |
| |
| Authors: | K. Tsuchiya, H. Higuchi, Y. Atarashi. |
| Date: | February 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2767 |
|
In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. |
|
| |
| RFC 2770 | GLOP Addressing in 233/8 |
| |
| Authors: | D. Meyer, P. Lothberg. |
| Date: | February 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3180 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2770 |
|
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors. |
|
| |
| RFC 2777 | Publicly Verifiable Nomcom Random Selection |
| |
|
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases. |
|
| |
| RFC 2787 | Definitions of Managed Objects for the Virtual Router Redundancy Protocol |
| |
| Authors: | B. Jewell, D. Chuang. |
| Date: | March 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2787 |
|
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router RedundancyProtocol (VRRP) [17].
This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2]. |
|
| |
| RFC 2793 | RTP Payload for Text Conversation |
| |
|
|
This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1].
Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.
This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. |
|
| |
| RFC 2796 | BGP Route Reflection - An Alternative to Full Mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet 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 thatAS. 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 2797 | Certificate Management Messages over CMS |
| |
| Authors: | M. Myers, X. Liu, J. Schaad, J. Weinstein. |
| Date: | April 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2797 |
|
This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys.
A small number of additional services are defined to supplement the core certificate request service.
Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. |
|
| |
| RFC 2800 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to theRFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 2806 | URLs for Telephone Calls |
| |
|
|
This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. |
|
| |
| RFC 2818 | HTTP Over TLS |
| |
|
|
This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP[RFC2817]. |
|
| |
| RFC 2821 | Simple Mail Transfer Protocol |
| |
|
|
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30],
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2], and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15].
Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship. |
|
| |
| RFC 2822 | Internet Message Format |
| |
|
|
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| RFC 2828 | Internet Security Glossary |
| |
|
|
This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future. |
|
| |
| RFC 2829 | Authentication Methods for LDAP |
| |
|
|
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. |
|
| |
| RFC 2830 | Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
| |
|
|
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request. |
|
| |
| RFC 2831 | Using Digest Authentication as a SASL Mechanism |
| |
|
|
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. |
|
| |
| RFC 2833 | RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals |
| |
|
|
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. |
|
| |
| RFC 2836 | Per Hop Behavior Identification Codes |
| |
| Authors: | S. Brim, B. Carpenter, F. Le Faucheur. |
| Date: | May 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3140 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2836 |
|
This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK] |
|
| |
| RFC 2837 | Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards. |
|
| |
| RFC 2842 | Capabilities Advertisement with BGP-4 |
| |
| Authors: | R. Chandra, J. Scudder. |
| Date: | May 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3392 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2842 |
|
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated. |
|
| |
| RFC 2845 | Secret Key Transaction Authentication for DNS (TSIG) |
| |
|
|
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. |
|
| |
| RFC 2851 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2851 |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.
This work is output from the Operations and Management Area "IPv6MIB" design team. |
|
| |
| RFC 2853 | Generic Security Service API Version 2 : Java Bindings |
| |
| Authors: | J. Kabat, M. Upadhyay. |
| Date: | June 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2853 |
|
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5]. |
|
| |
| RFC 2858 | Multiprotocol Extensions for BGP-4 |
| |
| Authors: | T. Bates, Y. Rekhter, R. Chandra, D. Katz. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2283 |
| Obsoleted by: | RFC 4760 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2858 |
|
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
This document obsoletes RFC 2283. |
|
| |
| RFC 2861 | TCP Congestion Window Validation |
| |
| Authors: | M. Handley, J. Padhye, S. Floyd. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7661 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2861 |
|
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD. |
|
| |
| RFC 2870 | Root Name Server Operational Requirements |
| |
| Authors: | R. Bush, D. Karrenberg, M. Kosters, R. Plzak. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2010 |
| Obsoleted by: | RFC 7720 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2870 |
|
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. |
|
| |
| RFC 2873 | TCP Processing of the IPv4 Precedence Field |
| |
| Authors: | X. Xiao, A. Hannan, V. Paxson, E. Crabbe. |
| Date: | June 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2873 |
|
This memo describes a conflict between TCP [RFC793] and DiffServ[RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.
Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet. |
|
| |
| RFC 2875 | Diffie-Hellman Proof-of-Possession Algorithms |
| |
| Authors: | H. Prafullchandra, J. Schaad. |
| Date: | July 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2875 |
|
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing. |
|
| |
| RFC 2877 | 5250 Telnet Enhancements |
| |
|
|
This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described.
By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange.
Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates.
This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. |
|
| |
| RFC 2878 | PPP Bridging Control Protocol (BCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. |
|
| |
| RFC 2885 | Megaco Protocol version 0.8 |
| |
| Authors: | F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. |
| Date: | August 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3015 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2885 |
|
This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 2886 | Megaco Errata |
| |
|
|
This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK] |
|
| |
| RFC 2893 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
|
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933. |
|
| |
| RFC 2898 | PKCS #5: Password-Based Cryptography Specification Version 2.0 |
| |
|
|
This memo represents a republication of PKCS #5 v2.0 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 that specification.
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.
The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS#8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints.
Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols[4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. |
|
| |
| RFC 2900 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 2908 | The Internet Multicast Address Allocation Architecture |
| |
| Authors: | D. Thaler, M. Handley, D. Estrin. |
| Date: | September 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6308 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2908 |
|
This document proposes a multicast address allocation architecture(MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism. |
|
| |
| RFC 2910 | Internet Printing Protocol/1.1: Encoding and Transport |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. |
| Date: | September 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2565 |
| Obsoleted by: | RFC 8010 |
| Updated by: | RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2910 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext TransferProtocol (HTTP) a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics [RFC2911]Internet Printing Protocol/1.1: Encoding and Transport (this document)Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.1. A few OPTIONAL operator operations have been added to IPP/1.1.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2911 | Internet Printing Protocol/1.1: Model and Semantics |
| |
|
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics (this document)Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called"application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2915 | The Naming Authority Pointer (NAPTR) DNS Resource Record |
| |
|
|
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label orUniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer(NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource DiscoverySystems to moving out-of-date services to new domains.
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR. |
|
| |
| RFC 2916 | E.164 number and DNS |
| |
|
|
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number.Routing of the actual connection using the service selected using these methods is not discussed. |
|
| |
| RFC 2925 | Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations |
| |
|
|
This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to anIP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. |
|
| |
| RFC 2929 | Domain Name System (DNS) IANA Considerations |
| |
| Authors: | D. Eastlake 3rd, E. Brunner-Williams, B. Manning. |
| Date: | September 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5395 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2929 |
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System(DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. |
|
| |
| RFC 2932 | IPv4 Multicast Routing MIB |
| |
| Authors: | K. McCloghrie, D. Farinacci, D. Thaler. |
| Date: | October 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2932 |
|
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 IPMulticast Routing for IPv4, independent of the specific multicast routing protocol in use. |
|
| |
| RFC 2933 | Internet Group Management Protocol MIB |
| |
| Authors: | K. McCloghrie, D. Farinacci, D. Thaler. |
| Date: | October 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2933 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing the InternetGroup Management Protocol (IGMP). |
|
| |
| RFC 2960 | Stream Control Transmission Protocol |
| |
| Authors: | R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. |
| Date: | October 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4960 |
| Updated by: | RFC 3309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2960 |
|
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 2965 | HTTP State Management Mechanism |
| |
|
|
This document specifies a way to create a stateful session withHypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109 and obsoletes it. |
|
| |
| RFC 2966 | Domain-wide Prefix Distribution with Two-Level IS-IS |
| |
| Authors: | T. Li, T. Przygienda, H. Smit. |
| Date: | October 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5302 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2966 |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. |
|
| |
| RFC 2976 | The SIP INFO Method |
| |
|
|
This document proposes an extension to the Session InitiationProtocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP andISDN signaling messages used to control telephony call services.
This and other example uses of the INFO method may be standardized in the future. |
|
| |
| RFC 2988 | Computing TCP's Retransmission Timer |
| |
| Authors: | V. Paxson, M. Allman. |
| Date: | November 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6298 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2988 |
|
This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. |
|
| |
| RFC 3000 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3001 | A URN Namespace of Object Identifiers |
| |
|
|
This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). |
|
| |
| RFC 3005 | IETF Discussion List Charter |
| |
|
|
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed.Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. |
|
| |
| RFC 3008 | Domain Name System Security (DNSSEC) Signing Authority |
| |
|
|
This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. |
|
| |
| RFC 3009 | Registration of parityfec MIME types |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | November 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3009 |
|
The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. |
|
| |
| RFC 3010 | NFS version 4 Protocol |
| |
| Authors: | S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. |
| Date: | December 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3010 |
|
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. |
|
| |
| RFC 3012 | Mobile IPv4 Challenge/Response Extensions |
| |
| Authors: | C. Perkins, P. Calhoun. |
| Date: | November 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4721 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3012 |
|
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. |
|
| |
| RFC 3015 | Megaco Protocol Version 1.0 |
| |
|
|
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 3016 | RTP Payload Format for MPEG-4 Audio/Visual Streams |
| |
| Authors: | Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. |
| Date: | November 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6416 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3016 |
|
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). |
|
| |
| RFC 3019 | IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol |
| |
| Authors: | B. Haberman, R. Worzella. |
| Date: | January 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3019 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710]. |
|
| |
| RFC 3023 | XML Media Types |
| |
|
|
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be". |
|
| |
| RFC 3025 | Mobile IP Vendor/Organization-Specific Extensions |
| |
| Authors: | G. Dommety, K. Leung. |
| Date: | February 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3115 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3025 |
|
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. |
|
| |
| RFC 3028 | Sieve: A Mail Filtering Language |
| |
|
|
This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 3036 | LDP Specification |
| |
| Authors: | L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5036 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3036 |
|
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 3039 | Internet X.509 Public Key Infrastructure Qualified Certificates Profile |
| |
| Authors: | S. Santesson, W. Polk, P. Barzin, M. Nystrom. |
| Date: | January 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3739 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3039 |
|
This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs.
It is important to note that the profile does not define any legal requirements for Qualified Certificates. |
|
| |
| RFC 3041 | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
| Authors: | T. Narten, R. Draves. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3041 |
|
Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. |
|
| |
| RFC 3044 | Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace |
| |
|
|
This document presents how the ISSN - International Standard SerialNumber - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier.
An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by theISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment.
This proceeds from concepts and proposals developed in several IETFRFCs emphasising the way to implement and to use "recognised" existing numbering system within the URN framework (RFC 2248, RFC2141, RFC 2611). |
|
| |
| RFC 3047 | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP. |
|
| |
| RFC 3057 | ISDN Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | February 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3057 |
|
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. |
|
| |
| RFC 3065 | Autonomous System Confederations for BGP |
| |
|
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. |
|
| |
| RFC 3066 | Tags for the Identification of Languages |
| |
|
|
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. |
|
| |
| RFC 3068 | An Anycast Prefix for 6to4 Relay Routers |
| |
|
|
This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned NumbersAuthority) of the "6to4 relay anycast prefix." |
|
| |
| RFC 3075 | XML-Signature Syntax and Processing |
| |
| Authors: | D. Eastlake 3rd, J. Reagle, D. Solo. |
| Date: | March 2001 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3075 |
|
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. |
|
| |
| 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 3107 | Carrying Label Information in BGP-4 |
| |
|
|
This document specifies the way in which the label mapping information for a particular route is piggybacked in the same BorderGateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching(MPLS) label which is mapped to that route. |
|
| |
| RFC 3119 | A More Loss-Tolerant RTP Payload Format for MP3 Audio |
| |
|
|
This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. |
|
| |
| RFC 3126 | Electronic Signature Formats for long term electronic signatures |
| |
| Authors: | D. Pinkas, J. Ross, N. Pope. |
| Date: | September 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5126 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3126 |
|
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and RFC2634, where, when appropriate additional signed and unsigned attributes have been defined.
The contents of this Informational RFC is technically equivalent toETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org |
|
| |
| RFC 3137 | OSPF Stub Router Advertisement |
| |
| Authors: | A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. |
| Date: | June 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6987 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3137 |
|
This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router.However, OSPF does not specify a standard way to accomplish this. |
|
| |
| RFC 3138 | Extended Assignments in 233/8 |
| |
|
|
This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. |
|
| |
| RFC 3152 | Delegation of IP6.ARPA |
| |
|
|
This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. |
|
| |
| RFC 3160 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
|
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. |
|
| |
| RFC 3164 | The BSD Syslog Protocol |
| |
|
|
This document describes the observed behavior of the syslog protocol.This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of CaliforniaBerkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices. |
|
| |
| RFC 3171 | IANA Guidelines for IPv4 Multicast Address Assignments |
| |
| Authors: | Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. |
| Date: | August 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5771 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3171 |
|
This memo provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. |
|
| |
| RFC 3177 | IAB/IESG Recommendations on IPv6 Address Allocations to Sites |
| |
|
|
This document provides recommendations to the addressing registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of/48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record. |
|
| |
| RFC 3184 | IETF Guidelines for Conduct |
| |
|
|
This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The Guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. |
|
| |
| RFC 3187 | Using International Standard Book Numbers as Uniform Resource Names |
| |
|
|
This document discusses how International Standard Book Numbers(ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. |
|
| |
| RFC 3188 | Using National Bibliography Numbers as Uniform Resource Names |
| |
|
|
This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. |
|
| |
| RFC 3189 | RTP Payload Format for DV (IEC 61834) Video |
| |
| Authors: | K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. |
| Date: | January 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6469 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3189 |
|
This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). |
|
| |
| RFC 3205 | On the use of HTTP as a Substrate |
| |
|
|
Recently there has been widespread interest in using HypertextTransfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. |
|
| |
| RFC 3211 | Password-based Encryption for CMS |
| |
|
|
This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. |
|
| |
| RFC 3220 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3230 | Instance Digests in HTTP |
| |
| Authors: | J. Mogul, A. Van Hoff. |
| Date: | January 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3230 |
|
HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1(Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. |
|
| |
| RFC 3242 | RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP |
| |
| Authors: | L-E. Jonsson, G. Pelletier. |
| Date: | April 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4362 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3242 |
|
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. |
|
| |
| RFC 3250 | Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration |
| |
| Authors: | L. McIntyre, G. Parsons, J. Rafferty. |
| Date: | September 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3250 |
|
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions. |
|
| |
| 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 3266 | Support for IPv6 in Session Description Protocol (SDP) |
| |
|
|
This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. |
|
| |
| RFC 3267 | Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs |
| |
| Authors: | J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. |
| Date: | June 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4867 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3267 |
|
This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both theRTP payload format and the storage format. |
|
| |
| RFC 3268 | Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) |
| |
|
|
This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) areRC2, RC4, International Data Encryption Algorithm (IDEA), DataEncryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. |
|
| |
| RFC 3272 | Overview and Principles of Internet Traffic Engineering |
| |
| Authors: | D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. |
| Date: | May 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9522 |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3272 |
|
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. |
|
| |
| RFC 3276 | Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing |
| |
|
|
This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-PairHigh-Speed Digital Subscriber Line (SHDSL) interfaces. |
|
| |
| RFC 3278 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Blake-Wilson, D. Brown, P. Lambert. |
| Date: | April 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5753 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3278 |
|
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
The readers attention is called to the Intellectual Property Rights section at the end of this document. |
|
| |
| 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 3281 | An Internet Attribute Certificate Profile for Authorization |
| |
| Authors: | S. Farrell, R. Housley. |
| Date: | April 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5755 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3281 |
|
This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. |
|
| |
| RFC 3285 | Using Microsoft Word to create Internet Drafts and RFCs |
| |
|
|
This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. |
|
| |
| RFC 3288 | Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) |
| |
| Authors: | E. O'Tuathail, M. Rose. |
| Date: | June 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4227 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3288 |
|
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. |
|
| |
| RFC 3291 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | May 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2851 |
| Obsoleted by: | RFC 4001 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3291 |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.
This document obsoletes RFC 2851. |
|
| |
| RFC 3300 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. |
| Date: | November 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 3000 |
| Obsoleted by: | RFC 3600 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3300 |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 24, 2002. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3309 | Stream Control Transmission Protocol (SCTP) Checksum Change |
| |
|
|
Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum. |
|
| |
| RFC 3315 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8415 |
| Updated by: | RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3315 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters. |
|
| |
| RFC 3316 | Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts |
| |
| Authors: | J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. |
| Date: | April 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7066 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3316 |
|
As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on howIPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or UniversalMobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. |
|
| |
| RFC 3330 | Special-Use IPv4 Addresses |
| |
|
|
This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. |
|
| |
| RFC 3332 | Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) |
| |
| Authors: | G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. |
| Date: | September 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3332 |
|
This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between twoIP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. |
|
| |
| RFC 3338 | Dual Stack Hosts Using "Bump-in-the-API" (BIA) |
| |
| Authors: | S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. |
| Date: | October 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3338 |
|
This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation. |
|
| |
| RFC 3344 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3356 | Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines |
| |
|
|
This document provides guidance to aid in the understanding of collaboration on standards development between the InternationalTelecommunication Union -- Telecommunication Standardization Sector(ITU-T) and the Internet Society (ISOC) / Internet Engineering TaskForce (IETF). It is an update of and obsoletes RFC 2436. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written. The bulk of this document is common text with ITU-TSupplement 3 to the ITU-T A-Series Recommendations.
Note: This was approved by ITU-T TSAG on 30 November 2001 as aSupplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). |
|
| |
| RFC 3369 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3373 | Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies |
| |
|
|
The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. |
|
| |
| RFC 3377 | Lightweight Directory Access Protocol (v3): Technical Specification |
| |
|
|
This document specifies the set of RFCs comprising the LightweightDirectory Access Protocol Version 3 (LDAPv3), and addresses the "IESGNote" attached to RFCs 2251 through 2256. |
|
| |
| RFC 3381 | Internet Printing Protocol (IPP): Job Progress Attributes |
| |
|
|
This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are drawn from the PWG Job Monitoring MIB. This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes. |
|
| |
| RFC 3382 | Internet Printing Protocol (IPP): The 'collection' attribute syntax |
| |
|
|
This document specifies an OPTIONAL attribute syntax called'collection' for use with the Internet Printing Protocol (IPP/1.0 andIPP/1.1). A 'collection' is a container holding one or more named values, which are called "member" attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. Finally, this document gives some illustrative example collection attribute definitions that are not intended as actual attribute specifications. |
|
| |
| RFC 3383 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | September 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4520 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3383 |
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 3388 | Grouping of Media Lines in the Session Description Protocol (SDP) |
| |
| Authors: | G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5888 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3388 |
|
This document defines two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several"m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces. |
|
| |
| RFC 3392 | Capabilities Advertisement with BGP-4 |
| |
|
|
This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 2842. |
|
| |
| RFC 3406 | Uniform Resource Names (URN) Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. |
| Date: | October 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2611 |
| Obsoleted by: | RFC 8141 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3406 |
|
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications inRFC 3401 and RFC 3405. The whole rests on the concept of individual"namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. |
|
| |
| RFC 3427 | Change Process for the Session Initiation Protocol (SIP) |
| |
|
|
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. |
|
| |
| RFC 3431 | Sieve Extension: Relational Tests |
| |
|
|
This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. |
|
| |
| RFC 3445 | Limiting the Scope of the KEY Resource Record (RR) |
| |
|
|
This document limits the Domain Name System (DNS) KEY Resource Record(RR) to only keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub- types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. |
|
| |
| RFC 3447 | Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 |
| |
|
|
This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. |
|
| |
| RFC 3448 | TCP Friendly Rate Control (TFRC): Protocol Specification |
| |
| Authors: | M. Handley, S. Floyd, J. Padhye, J. Widmer. |
| Date: | January 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5348 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3448 |
|
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. |
|
| |
| RFC 3450 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5775 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3450 |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. |
|
| |
| RFC 3451 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5651 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3451 |
|
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. |
|
| |
| RFC 3452 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5052, RFC 5445 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3452 |
|
This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast". |
|
| |
| RFC 3454 | Preparation of Internationalized Strings ("stringprep") |
| |
| Authors: | P. Hoffman, M. Blanchet. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3454 |
|
This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. |
|
| |
| RFC 3455 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) |
| |
| Authors: | M. Garcia-Martin, E. Henrikson, D. Mills. |
| Date: | January 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7315 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3455 |
|
This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. |
|
| |
| RFC 3462 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.
This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. |
|
| |
| RFC 3466 | A Model for Content Internetworking (CDI) |
| |
| Authors: | M. Day, B. Cain, G. Tomlinson, P. Rzewski. |
| Date: | February 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7336 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3466 |
|
Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called"content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. |
|
| |
| RFC 3484 | Default Address Selection for Internet Protocol version 6 (IPv6) |
| |
|
|
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. |
|
| |
| RFC 3489 | STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |
| |
| Authors: | J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5389 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3489 |
|
Simple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure. |
|
| |
| RFC 3490 | Internationalizing Domain Names in Applications (IDNA) |
| |
|
|
Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. |
|
| |
| RFC 3491 | Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) |
| |
| Authors: | P. Hoffman, M. Blanchet. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5891 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3491 |
|
This document describes how to prepare internationalized domain name(IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). |
|
| |
| RFC 3501 | INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 |
| |
| Authors: | M. Crispin. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 2060 |
| Obsoleted by: | RFC 9051 |
| Updated by: | RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3501 |
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers.These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. |
|
| |
| RFC 3511 | Benchmarking Methodology for Firewall Performance |
| |
| Authors: | B. Hickman, D. Newman, S. Tadjudin, T. Martin. |
| Date: | April 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9411 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3511 |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.
This document is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 3513 | Internet Protocol Version 6 (IPv6) Addressing Architecture |
| |
|
|
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses. |
|
| |
| RFC 3517 | A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP |
| |
| Authors: | E. Blanton, M. Allman, K. Fall, L. Wang. |
| Date: | April 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6675 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3517 |
|
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. |
|
| |
| RFC 3525 | Gateway Control Protocol Version 1 |
| |
| Authors: | C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed.. |
| Date: | June 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 3015 |
| Obsoleted by: | RFC 5125 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3525 |
|
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and aMedia Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.
This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T StudyGroup 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the MegacoE-mail list and incorporated into the Study Group 16 Implementor'sGuide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1.Because of ITU-T renumbering, it was published by the ITU-T asRecommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
Users of this specification are advised to consult the H.248 Sub- series Implementors' Guide at http://www.itu.int/itudoc/itu- t/com16/implgd for additional corrections and clarifications. |
|
| |
| RFC 3530 | Network File System (NFS) version 4 Protocol |
| |
| Authors: | S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. |
| Date: | April 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 3010 |
| Obsoleted by: | RFC 7530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3530 |
|
The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in anInternet environment.
This document replaces RFC 3010 as the definition of the NFS version4 protocol. |
|
| |
| RFC 3534 | The application/ogg Media Type |
| |
|
|
The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectual property concerns. |
|
| |
| RFC 3536 | Terminology Used in Internationalization in the IETF |
| |
|
|
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. |
|
| |
| RFC 3546 | Transport Layer Security (TLS) Extensions |
| |
| Authors: | S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. |
| Date: | June 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4366 |
| Updates: | RFC 2246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3546 |
|
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. |
|
| |
| RFC 3547 | The Group Domain of Interpretation |
| |
| Authors: | M. Baugher, B. Weis, T. Hardjono, H. Harney. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6407 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3547 |
|
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. TheGDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. |
|
| |
| RFC 3548 | The Base16, Base32, and Base64 Data Encodings |
| |
|
|
This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. |
|
| |
| RFC 3555 | MIME Type Registration of RTP Payload Formats |
| |
|
|
This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences asMIME subtypes. Some of these may also be used for transfer modes other than RTP. |
|
| |
| RFC 3567 | Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication |
| |
|
|
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. |
|
| |
| RFC 3570 | Content Internetworking (CDI) Scenarios |
| |
| Authors: | P. Rzewski, M. Day, D. Gilletti. |
| Date: | July 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6770 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3570 |
|
In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. |
|
| |
| RFC 3576 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5176 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3576 |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 3588 | Diameter Base Protocol |
| |
|
|
The Diameter base protocol is intended to provide an Authentication,Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by allDiameter applications. The Diameter base application needs to be supported by all Diameter implementations. |
|
| |
| RFC 3598 | Sieve Email Filtering -- Subaddress Extension |
| |
|
|
On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. |
|
| |
| RFC 3600 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3603 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | W. Marshall, Ed., F. Andreasen, Ed.. |
| Date: | October 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5503 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3603 |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 3627 | Use of /127 Prefix Length Between Routers Considered Harmful |
| |
|
|
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. |
|
| |
| RFC 3633 | IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 |
| |
|
|
The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host ConfigurationProtocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. |
|
| |
| RFC 3636 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 MediumAttachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. |
|
| |
| RFC 3655 | Redefinition of DNS Authenticated Data (AD) bit |
| |
|
|
This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy. |
|
| |
| RFC 3658 | Delegation Signer (DS) Resource Record (RR) |
| |
|
|
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.
This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090. |
|
| |
| RFC 3662 | A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services |
| |
| Authors: | R. Bless, K. Nichols, K. Wehrle. |
| Date: | December 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8622 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3662 |
|
This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. |
|
| |
| RFC 3664 | The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
|
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, called AES-XCBC-PRF-128. |
|
| |
| RFC 3667 | IETF Rights in Contributions |
| |
|
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC2026. |
|
| |
| RFC 3668 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3674 | Feature Discovery in Lightweight Directory Access Protocol (LDAP) |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms. |
|
| |
| RFC 3682 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5082 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3682 |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. |
|
| |
| RFC 3685 | SIEVE Email Filtering: Spamtest and VirusTest Extensions |
| |
|
|
The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. |
|
| |
| RFC 3695 | Compact Forward Error Correction (FEC) Schemes |
| |
|
|
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. |
|
| |
| RFC 3697 | IPv6 Flow Label Specification |
| |
| Authors: | J. Rajahalme, A. Conta, B. Carpenter, S. Deering. |
| Date: | March 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6437 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3697 |
|
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. |
|
| |
| RFC 3700 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3709 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
| Authors: | S. Santesson, R. Housley, T. Freeman. |
| Date: | February 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9399 |
| Updated by: | RFC 6170 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3709 |
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. |
|
| |
| RFC 3712 | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
| Authors: | P. Fleming, I. McDonald. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7612 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3712 |
|
This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that supportLightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). |
|
| |
| RFC 3720 | Internet Small Computer Systems Interface (iSCSI) |
| |
|
|
This document describes a transport protocol for Internet SmallComputer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.
SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).
As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. |
|
| |
| RFC 3730 | Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. |
|
| |
| RFC 3731 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. |
|
| |
| RFC 3732 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. |
|
| |
| RFC 3733 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. |
|
| |
| RFC 3734 | Extensible Provisioning Protocol (EPP) Transport Over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. |
|
| |
| RFC 3736 | Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 |
| |
|
|
Stateless Dynamic Host Configuration Protocol service for IPv6(DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. |
|
| |
| RFC 3755 | Legacy Resolver Compatibility for Delegation Signer (DS) |
| |
|
|
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. |
|
| |
| RFC 3757 | Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag |
| |
|
|
With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the DomainName System KEY (DNSKEY) resource record set. A flag bit in theDNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC2535 and RFC 3755. |
|
| |
| RFC 3761 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
|
|
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. |
|
| |
| RFC 3768 | Virtual Router Redundancy Protocol (VRRP) |
| |
|
|
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
|
| |
| RFC 3770 | Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
| |
|
|
This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). |
|
| |
| RFC 3771 | The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message |
| |
|
|
This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). TheIntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAPExtendedRequest and ExtendedResponse to define new single- request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. |
|
| |
| RFC 3775 | Mobility Support in IPv6 |
| |
| Authors: | D. Johnson, C. Perkins, J. Arkko. |
| Date: | June 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3775 |
|
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 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 the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation,Mobile IPv6 defines a new IPv6 protocol and a new destination option.All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. |
|
| |
| RFC 3777 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 3778 | The application/pdf Media Type |
| |
| Authors: | E. Taft, J. Pravetz, S. Zilles, L. Masinter. |
| Date: | May 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8118 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3778 |
|
PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of thePDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. |
|
| |
| RFC 3782 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
|
|
The purpose of this document is to advance NewReno TCP's FastRetransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewRenoTCP. |
|
| |
| RFC 3784 | Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 3786 | Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit |
| |
| Authors: | A. Hermelin, S. Previdi, M. Shand. |
| Date: | May 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5311 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3786 |
|
This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. |
|
| |
| RFC 3798 | Message Disposition Notification |
| |
|
|
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
|
| |
| RFC 3825 | Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information |
| |
| Authors: | J. Polk, J. Schnizlein, M. Linsner. |
| Date: | July 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6225 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3825 |
|
This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. TheLocation Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. |
|
| |
| RFC 3831 | Transmission of IPv6 Packets over Fibre Channel |
| |
|
|
This document specifies the way of encapsulating IPv6 packets overFibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. |
|
| |
| RFC 3845 | DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format |
| |
|
|
This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. |
|
| |
| RFC 3847 | Restart Signaling for Intermediate System to Intermediate System (IS-IS) |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. |
|
| |
| RFC 3850 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling |
| |
|
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the InternetX.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. |
|
| |
| RFC 3851 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification |
| |
|
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. |
|
| |
| RFC 3852 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3895 | Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2495. |
|
| |
| RFC 3920 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. |
|
| |
| RFC 3921 | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence |
| |
| Authors: | P. Saint-Andre, Ed.. |
| Date: | October 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6121 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3921 |
|
This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. |
|
| |
| RFC 3926 | FLUTE - File Delivery over Unidirectional Transport |
| |
| Authors: | T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. |
| Date: | October 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6726 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3926 |
|
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous LayeredCoding, the base protocol designed for massively scalable multicast distribution. |
|
| |
| RFC 3932 | The IESG and RFC Editor Documents: Procedures |
| |
|
|
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 3940 | Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5740 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3940 |
|
This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. |
|
| |
| RFC 3941 | Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5401 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3941 |
|
This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. |
|
| |
| RFC 3946 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
| Authors: | E. Mannie, D. Papadimitriou. |
| Date: | October 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3946 |
|
This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. |
|
| |
| RFC 3978 | IETF Rights in Contributions |
| |
|
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC2026. |
|
| |
| RFC 3979 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3980 | T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names |
| |
|
|
Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information TechnologyStandards (INCITS) T11 - Fibre Channel (FC) protocols and used bySerial Attached SCSI (SAS). This document updates RFC 3720. |
|
| |
| RFC 3984 | RTP Payload Format for H.264 Video |
| |
| Authors: | S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6184 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3984 |
|
This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network AbstractionLayer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, toInternet video streaming with interleaved transmission, to high bit- rate video-on-demand. |
|
| |
| RFC 3989 | Middlebox Communications (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5189 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3989 |
|
This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions. |
|
| |
| RFC 4005 | Diameter Network Access Server Application |
| |
| Authors: | P. Calhoun, G. Zorn, D. Spence, D. Mitton. |
| Date: | August 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4005 |
|
This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting (AAA) services in theNetwork Access Server (NAS) environment. When combined with theDiameter Base protocol, Transport Profile, and ExtensibleAuthentication Protocol specifications, this application specification satisfies typical network access services requirements.
Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS andDiameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.
The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. |
|
| |
| RFC 4006 | Diameter Credit-Control Application |
| |
| Authors: | H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. |
| Date: | August 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8506 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4006 |
|
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. |
|
| |
| RFC 4008 | Definitions of Managed Objects for Network Address Translators (NAT) |
| |
| Authors: | R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7658 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4008 |
|
This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function.This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. |
|
| |
| RFC 4009 | The SEED Encryption Algorithm |
| |
| Authors: | J. Park, S. Lee, J. Kim, J. Lee. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4269 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4009 |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). |
|
| |
| RFC 4013 | SASLprep: Stringprep Profile for User Names and Passwords |
| |
|
|
This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the"SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used bySimple Authentication and Security Layer (SASL) mechanisms (such asPLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. |
|
| |
| RFC 4020 | Early IANA Allocation of Standards Track Code Points |
| |
| Authors: | K. Kompella, A. Zinin. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7120 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4020 |
|
This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. |
|
| |
| RFC 4049 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
|
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. |
|
| |
| RFC 4051 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
A number of Uniform Resource Identifiers (URIs) intended for use withXML Digital Signatures, Encryption, and Canonicalization are defined.These URIs identify algorithms and types of keying information. |
|
| |
| RFC 4068 | Fast Handovers for Mobile IPv6 |
| |
|
|
Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 4071 | Structure of the IETF Administrative Support Activity (IASA) |
| |
|
|
This document describes the structure of the IETF AdministrativeSupport Activity (IASA) as an activity housed within the InternetSociety (ISOC). It defines the roles and responsibilities of theIETF Administrative Oversight Committee (IAOC), the IETFAdministrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. |
|
| |
| RFC 4091 | The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4091 |
|
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. |
|
| |
| RFC 4092 | Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4092 |
|
This document describes how to use the Alternative Network AddressTypes (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. |
|
| |
| RFC 4132 | Addition of Camellia Cipher Suites to Transport Layer Security (TLS) |
| |
| Authors: | S. Moriai, A. Kato, M. Kanda. |
| Date: | July 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5932 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4132 |
|
This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. |
|
| |
| RFC 4133 | Entity MIB (Version 3) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). |
|
| |
| RFC 4140 | Hierarchical Mobile IPv6 Mobility Management (HMIPv6) |
| |
| Authors: | H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. |
| Date: | August 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5380 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4140 |
|
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. |
|
| |
| RFC 4148 | IP Performance Metrics (IPPM) Metrics Registry |
| |
|
|
This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.
This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.
IANA has been assigned to administer this new registry. |
|
| |
| RFC 4205 | Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 4214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, M. Talwar, D. Thaler. |
| Date: | October 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5214 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4214 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. |
|
| |
| RFC 4234 | Augmented BNF for Syntax Specifications: ABNF |
| |
|
|
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. |
|
| |
| RFC 4242 | Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | S. Venaas, T. Chown, B. Volz. |
| Date: | November 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8415 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4242 |
|
This document describes a Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved fromDHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. |
|
| |
| RFC 4244 | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
|
|
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. |
|
| |
| RFC 4281 | The Codecs Parameter for "Bucket" Media Types |
| |
| Authors: | R. Gellens, D. Singer, P. Frojdh. |
| Date: | November 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4281 |
|
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from theContent-Type alone if the content can be rendered.
This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) |
|
| |
| RFC 4282 | The Network Access Identifier |
| |
| Authors: | B. Aboba, M. Beadles, J. Arkko, P. Eronen. |
| Date: | December 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2486 |
| Obsoleted by: | RFC 7542 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4282 |
|
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple InternetService Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. |
|
| |
| RFC 4288 | Media Type Specifications and Registration Procedures |
| |
|
|
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. |
|
| |
| RFC 4294 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. |
|
| |
| RFC 4305 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4306 | Internet Key Exchange (IKEv2) Protocol |
| |
|
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations(SAs).
This version of the IKE specification combines the contents of what were previously separate documents, including Internet SecurityAssociation and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC2409), the Internet Domain of Interpretation (DOI, RFC 2407), NetworkAddress Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. |
|
| |
| RFC 4307 | Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4310 | Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. |
|
| |
| RFC 4325 | Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension |
| |
|
|
This document updates RFC 3280 by defining the Authority InformationAccess Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. |
|
| |
| RFC 4327 | Link Management Protocol (LMP) Management Information Base (MIB) |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. |
| Date: | January 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4631 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4327 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP). |
|
| |
| RFC 4329 | Scripting Media Types |
| |
|
|
This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. |
|
| |
| RFC 4330 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP. |
|
| |
| RFC 4333 | The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process |
| |
| Authors: | G. Huston, Ed., B. Wijnen, Ed.. |
| Date: | December 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8711 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4333 |
|
This memo outlines the guidelines for selection of members of theIETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. |
|
| |
| RFC 4346 | The Transport Layer Security (TLS) Protocol Version 1.1 |
| |
|
|
This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 4347 | Datagram Transport Layer Security |
| |
|
|
This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. |
|
| |
| RFC 4366 | Transport Layer Security (TLS) Extensions |
| |
|
|
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. |
|
| |
| RFC 4369 | Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) |
| |
| Authors: | K. Gibbons, C. Monia, J. Tseng, F. Travostino. |
| Date: | January 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4369 |
|
The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. |
|
| |
| RFC 4371 | BCP 101 Update for IPR Trust |
| |
|
|
This document updates BCP 101 to take account of the new IETFIntellectual Property Trust. |
|
| |
| RFC 4379 | Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures |
| |
|
|
This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching(MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. |
|
| |
| RFC 4395 | Guidelines and Registration Procedures for New URI Schemes |
| |
|
|
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. |
|
| |
| RFC 4402 | A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism |
| |
|
|
This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. |
|
| |
| RFC 4408 | Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |
| |
|
|
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. |
|
| |
| RFC 4409 | Message Submission for Mail |
| |
|
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay and final delivery are unaffected, and continue to useSMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
| |
| RFC 4420 | Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs. |
|
| |
| RFC 4423 | Host Identity Protocol (HIP) Architecture |
| |
| Authors: | R. Moskowitz, P. Nikander. |
| Date: | May 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9063 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4423 |
|
This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, theHost Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since.This document represents one stable point in that evolution of understanding. |
|
| |
| RFC 4441 | The IEEE 802/IETF Relationship |
| |
|
|
Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs andAuthentication, Authorization, and Accounting (AAA) applications.This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. |
|
| |
| RFC 4447 | Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) |
| |
|
|
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. |
|
| |
| RFC 4460 | Stream Control Transmission Protocol (SCTP) Specification Errata and Issues |
| |
| Authors: | R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. |
| Date: | April 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4460 |
|
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied.In addition to the delta, a description of the problem and the details of the solution are also provided. |
|
| |
| RFC 4474 | Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, C. Jennings. |
| Date: | August 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8224 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4474 |
|
The existing security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. |
|
| |
| RFC 4492 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. |
|
| |
| RFC 4507 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
| Authors: | J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4507 |
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. |
|
| |
| RFC 4544 | Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Bakke, M. Krueger, T. McSweeney, J. Muchow. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7147 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4544 |
|
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 a client using theInternet Small Computer System Interface (iSCSI) protocol (SCSI overTCP). |
|
| |
| RFC 4550 | Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
| Authors: | S. Maes, A. Melnikov. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4550 |
|
This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). |
|
| |
| RFC 4551 | IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization |
| |
|
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
This document defines an extension to IMAP (RFC 3501). |
|
| |
| RFC 4566 | SDP: Session Description Protocol |
| |
|
|
This memo 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. |
|
| |
| RFC 4572 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document extends and updates RFC 4145. |
|
| |
| RFC 4582 | The Binary Floor Control Protocol (BFCP) |
| |
|
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. |
|
| |
| RFC 4583 | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
|
This document specifies how to describe Binary Floor Control Protocol(BFCP) streams in Session Description Protocol (SDP) descriptions.User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. |
|
| |
| RFC 4590 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | July 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4590 |
|
This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP. |
|
| |
| RFC 4601 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.
This document obsoletes RFC 2362, an Experimental version of PIM-SM. |
|
| |
| RFC 4614 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7414 |
| Updated by: | RFC 6247 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4614 |
|
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. |
|
| |
| RFC 4622 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP). |
|
| |
| RFC 4627 | The application/json Media Type for JavaScript Object Notation (JSON) |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. |
|
| |
| RFC 4630 | Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document updates the handling of DirectoryString in the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding.The requirement for exclusive use of UTF8String after December 31,2003 is removed. |
|
| |
| RFC 4634 | US Secure Hash Algorithms (SHA and HMAC-SHA) |
| |
|
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), specifically SHA-224 (RFC3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. |
|
| |
| RFC 4635 | HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers |
| |
|
|
Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.Currently, identifiers have been specified only for HMAC MD5 (HashedMessage Authentication Code, Message Digest 5) and GSS (GenericSecurity Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA(Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. |
|
| |
| RFC 4641 | DNSSEC Operational Practices |
| |
|
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. |
|
| |
| RFC 4646 | Tags for Identifying Languages |
| |
|
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. |
|
| |
| RFC 4676 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
|
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4677 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
|
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. |
|
| |
| RFC 4693 | IETF Operational Notes |
| |
|
|
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
It proposes to establish this series as an RFC 3933 process experiment. |
|
| |
| RFC 4695 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6295 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4695 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. |
|
| |
| RFC 4718 | IKEv2 Clarifications and Implementation Guidelines |
| |
| Authors: | P. Eronen, P. Hoffman. |
| Date: | October 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4718 |
|
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. |
|
| |
| RFC 4722 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5022 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4722 |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 4741 | NETCONF Configuration Protocol |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. |
|
| |
| RFC 4742 | Using the NETCONF Configuration Protocol over Secure SHell (SSH) |
| |
| Authors: | M. Wasserman, T. Goddard. |
| Date: | December 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6242 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4742 |
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. |
|
| |
| RFC 4748 | RFC 3978 Update to Recognize the IETF Trust |
| |
|
|
This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of allIETF-related intellectual property rights.
This document does not constrain how the IETF Trust exercises those rights. |
|
| |
| RFC 4753 | ECP Groups For IKE and IKEv2 |
| |
|
|
This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to alignIKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. |
|
| |
| RFC 4756 | Forward Error Correction Grouping Semantics in Session Description Protocol |
| |
|
|
This document defines the semantics that allow for grouping ofForward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in theSession Description Protocol" (RFC 3388) to group together "m" lines in the same session. |
|
| |
| RFC 4770 | vCard Extensions for Instant Messaging (IM) |
| |
| Authors: | C. Jennings, J. Reschke, Ed.. |
| Date: | January 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4770 |
|
This document describes an extension to vCard to support InstantMessaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. |
|
| |
| RFC 4773 | Administration of the IANA Special Purpose IPv6 Address Block |
| |
|
|
This is a direction to IANA concerning the management of the IANASpecial Purpose IPv6 address assignment registry. |
|
| |
| RFC 4813 | OSPF Link-Local Signaling |
| |
| Authors: | B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5613 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4813 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. |
|
| |
| RFC 4835 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4843 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) |
| |
| Authors: | P. Nikander, J. Laganier, F. Dupont. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7343 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4843 |
|
This document introduces Overlay Routable Cryptographic HashIdentifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application ProgrammingInterfaces (API) and not as identifiers for network location at theIP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with currentIPv6 addresses.
This document requests IANA to allocate a temporary prefix out of theIPv6 addressing space for Overlay Routable Cryptographic HashIdentifiers. By default, the prefix will be returned to IANA in2014, with continued use requiring IETF consensus. |
|
| |
| RFC 4844 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. |
|
| |
| RFC 4850 | Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture |
| |
|
|
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. |
|
| |
| RFC 4869 | Suite B Cryptographic Suites for IPsec |
| |
|
|
This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with theUnited States National Security Agency's Suite B specifications. |
|
| |
| RFC 4870 | Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) |
| |
|
|
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
Proof and protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4871 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4879 | Clarification of the Third Party Disclosure Procedure in RFC 3979 |
| |
|
|
This document clarifies and updates a single sentence in RFC 3979.Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF ExecutiveDirector notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. |
|
| |
| RFC 4893 | BGP Support for Four-octet AS Number Space |
| |
|
|
Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry theAutonomous System number as a four-octet entity. |
|
| |
| RFC 4909 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport |
| |
|
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 4930 | Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. |
|
| |
| RFC 4931 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 3731. |
|
| |
| RFC 4932 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 3732. |
|
| |
| RFC 4933 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. |
|
| |
| RFC 4934 | Extensible Provisioning Protocol (EPP) Transport Over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 3734. |
|
| |
| RFC 4938 | PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
|
|
This document extends the Point-to-Point over Ethernet (PPPoE)Protocol with a credit-based flow control mechanism and Link QualityMetric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. |
|
| |
| RFC 4941 | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
|
|
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. |
|
| |
| RFC 4952 | Overview and Framework for Internationalized Email |
| |
|
|
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. |
|
| |
| RFC 4960 | Stream Control Transmission Protocol |
| |
|
|
This document obsoletes RFC 2960 and RFC 3309. It describes theStream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
-- optional bundling of multiple user messages into a single SCTP packet, and
-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 4970 | Extensions to OSPF for Advertising Optional Router Capabilities |
| |
| Authors: | A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7770 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4970 |
|
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. A new RouterInformation (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a newLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). |
|
| |
| RFC 4971 | Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information |
| |
| Authors: | JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed.. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7981 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4971 |
|
This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. |
|
| |
| RFC 4995 | The RObust Header Compression (ROHC) Framework |
| |
| Authors: | L-E. Jonsson, G. Pelletier, K. Sandlund. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5795 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4995 |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. |
|
| |
| RFC 4996 | RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) |
| |
| Authors: | G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. |
| Date: | July 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6846 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4996 |
|
This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.
ROHC-TCP works 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. |
|
| |
| RFC 5000 | Internet Official Protocol Standards |
| |
|
|
This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, andExperimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.
For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. |
|
| |
| RFC 5006 | IPv6 Router Advertisement Option for DNS Configuration |
| |
| Authors: | J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. |
| Date: | September 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6106 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5006 |
|
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts. |
|
| |
| RFC 5008 | Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
|
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 3851. |
|
| |
| RFC 5046 | Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) |
| |
| Authors: | M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7145 |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5046 |
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. |
|
| |
| RFC 5048 | Internet Small Computer System Interface (iSCSI) Corrections and Clarifications |
| |
|
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition inRFC 3720 to serve as a companion document for the iSCSI implementers.This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. |
|
| |
| RFC 5070 | The Incident Object Description Exchange Format |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams(CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. |
|
| |
| RFC 5075 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | November 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5175 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5075 |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. |
|
| |
| RFC 5077 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
|
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletesRFC 4507. |
|
| |
| RFC 5078 | IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline |
| |
|
|
RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in theNomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson(2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. |
|
| |
| RFC 5081 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
|
|
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. |
|
| |
| RFC 5101 | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information |
| |
|
|
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. |
|
| |
| RFC 5102 | Information Model for IP Flow Information Export |
| |
| Authors: | J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7012 |
| Updated by: | RFC 6313 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5102 |
|
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. |
|
| |
| RFC 5117 | RTP Topologies |
| |
| Authors: | M. Westerlund, S. Wenger. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7667 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5117 |
|
This document discusses multi-endpoint topologies used in Real-timeTransport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. |
|
| |
| RFC 5143 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation |
| |
| Authors: | A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. |
| Date: | February 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4842 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5143 |
|
This document describes a historical method for encapsulatingSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Path signals for transport across packet-switched networks (PSNs).The PSNs explicitly supported by this document include MPLS and IP.Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. |
|
| |
| RFC 5156 | Special-Use IPv6 Addresses |
| |
|
|
This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. |
|
| |
| RFC 5157 | IPv6 Implications for Network Scanning |
| |
|
|
The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discoverIPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. |
|
| |
| RFC 5162 | IMAP4 Extensions for Quick Mailbox Resynchronization |
| |
| Authors: | A. Melnikov, D. Cridland, C. Wilson. |
| Date: | March 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7162 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5162 |
|
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). |
|
| |
| RFC 5201 | Host Identity Protocol |
| |
| Authors: | R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7401 |
| Updated by: | RFC 6253 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5201 |
|
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. |
|
| |
| RFC 5202 | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
| Authors: | P. Jokela, R. Moskowitz, P. Nikander. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7402 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5202 |
|
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). |
|
| |
| RFC 5203 | Host Identity Protocol (HIP) Registration Extension |
| |
| Authors: | J. Laganier, T. Koponen, L. Eggert. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8003 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5203 |
|
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. |
|
| |
| RFC 5204 | Host Identity Protocol (HIP) Rendezvous Extension |
| |
|
|
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. |
|
| |
| RFC 5205 | Host Identity Protocol (HIP) Domain Name System (DNS) Extensions |
| |
| Authors: | P. Nikander, J. Laganier. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8005 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5205 |
|
This document specifies a new resource record (RR) for the DomainName System (DNS), and how to use it with the Host Identity Protocol(HIP). This RR allows a HIP node to store in the DNS its HostIdentity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). |
|
| |
| RFC 5206 | End-Host Mobility and Multihoming with the Host Identity Protocol |
| |
| Authors: | P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8046 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5206 |
|
This document defines mobility and multihoming extensions to the HostIdentity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. |
|
| |
| RFC 5208 | Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 |
| |
|
|
This document represents a republication of PKCS #8 v1.2 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.
This document describes a syntax for private-key information. |
|
| |
| RFC 5226 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all 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 IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. IfIANA is expected to play a role in the management of a namespace,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 namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434. |
|
| |
| RFC 5245 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called InteractiveConnectivity Establishment (ICE). ICE makes use of the SessionTraversal Utilities for NAT (STUN) protocol and its extension,Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session InitiationProtocol (SIP). |
|
| |
| RFC 5246 | The Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | T. Dierks, E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3268, RFC 4346, RFC 4366 |
| Obsoleted by: | RFC 8446 |
| Updates: | RFC 4492 |
| Updated by: | RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5246 |
|
This document specifies Version 1.2 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 5268 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, andBinding Update, is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 5285 | A General Mechanism for RTP Header Extensions |
| |
| Authors: | D. Singer, H. Desineni. |
| Date: | July 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8285 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5285 |
|
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. |
|
| |
| RFC 5296 | EAP Extensions for EAP Re-authentication Protocol (ERP) |
| |
| Authors: | V. Narayanan, L. Dondeti. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6696 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5296 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. |
|
| |
| RFC 5306 | Restart Signaling for IS-IS |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. |
|
| |
| RFC 5316 | ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
| |
| Authors: | M. Chen, R. Zhang, X. Duan. |
| Date: | December 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9346 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5316 |
|
This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems(ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document. |
|
| |
| RFC 5335 | Internationalized Email Headers |
| |
|
|
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. |
|
| |
| RFC 5336 | SMTP Extension for Internationalized Email Addresses |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. |
|
| |
| RFC 5337 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC3798. |
|
| |
| RFC 5342 | IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters inIETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). |
|
| |
| RFC 5377 | Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents |
| |
|
|
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. |
|
| |
| RFC 5389 | Session Traversal Utilities for NAT (STUN) |
| |
|
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network AddressTranslator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489. |
|
| |
| RFC 5395 | Domain Name System (DNS) IANA Considerations |
| |
|
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System(DNS) resource record types, CLASSes, operation codes, error codes,DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 5405 | Unicast UDP Usage Guidelines for Application Designers |
| |
| Authors: | L. Eggert, G. Fairhurst. |
| Date: | November 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8085 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5405 |
|
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.Because congestion control is critical to the stable operation of theInternet, applications and upper-layer protocols that choose to useUDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use ofUDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. |
|
| |
| RFC 5414 | Wireless LAN Control Protocol (WiCoP) |
| |
| Authors: | S. Iino, S. Govindan, M. Sugiura, H. Cheng. |
| Date: | February 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5415 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5414 |
|
The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of WirelessAccess Points (CAPWAP). |
|
| |
| RFC 5430 | Suite B Profile for Transport Layer Security (TLS) |
| |
| Authors: | M. Salter, E. Rescorla, R. Housley. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6460 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5430 |
|
The United States government has published guidelines for "NSA SuiteB Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. |
|
| |
| RFC 5451 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.Any receiver-side software, such as mail filters or Mail User Agents(MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
|
| |
| RFC 5467 | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6387 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5467 |
|
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. |
|
| |
| RFC 5469 | DES and IDEA Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES(when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. |
|
| |
| RFC 5504 | Downgrading Mechanism for Email Address Internationalization |
| |
| Authors: | K. Fujiwara, Ed., Y. Yoneya, Ed.. |
| Date: | March 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6530 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5504 |
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. |
|
| |
| RFC 5512 | The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute |
| |
| Authors: | P. Mohapatra, E. Rosen. |
| Date: | April 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5512 |
|
In certain situations, transporting a packet from one Border GatewayProtocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the"encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such asLayer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic RoutingEncapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using theEncapsulation Subsequent Address Family Identifier (SAFI) and theIPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. |
|
| |
| RFC 5539 | NETCONF over Transport Layer Security (TLS) |
| |
|
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. |
|
| |
| RFC 5549 | Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop |
| |
| Authors: | F. Le Faucheur, E. Rosen. |
| Date: | May 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5549 |
|
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and theSubsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowingMP-BGP Peers to dynamically discover whether they can exchange IPv4NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. |
|
| |
| RFC 5566 | BGP IPsec Tunnel Encapsulation Attribute |
| |
| Authors: | L. Berger, R. White, E. Rosen. |
| Date: | June 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5566 |
|
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for GenericRouting Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), andIP in IP tunnel types are defined. This document defines support forIPsec tunnel types. |
|
| |
| RFC 5575 | Dissemination of Flow Specification Rules |
| |
| Authors: | P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8955 |
| Updated by: | RFC 7674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5575 |
|
This document defines a new Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate(distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. |
|
| |
| RFC 5620 | RFC Editor Model (Version 1) |
| |
|
|
The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent SubmissionEditor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional)Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. |
|
| |
| RFC 5633 | Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers |
| |
|
|
This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. |
|
| |
| RFC 5653 | Generic Security Service API Version 2: Java Bindings Update |
| |
|
|
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in"Generic Security Service API Version 2 : Java Bindings" (RFC 2853).This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "TheKerberos Version 5 Generic Security Service Application ProgramInterface (GSS-API) Mechanism: Version 2" (RFC 4121). |
|
| |
| RFC 5661 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, DirectoryDelegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior toNFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. |
|
| |
| RFC 5666 | Remote Direct Memory Access Transport for Remote Procedure Call |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5666 |
|
This document describes a protocol providing Remote Direct MemoryAccess (RDMA) as a new transport for Remote Procedure Call (RPC).The RDMA transport binding conveys the benefits of efficient, bulk- data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. |
|
| |
| RFC 5667 | Network File System (NFS) Direct Data Placement |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5667 |
|
This document defines the bindings of the various Network File System(NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2,3, 4, and 4.1 over such an RDMA transport. |
|
| |
| RFC 5672 | RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update |
| |
|
|
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.The Update is in the style of an Errata entry, albeit a rather long one. |
|
| |
| RFC 5680 | The Nominating Committee Process: Open Disclosure of Willing Nominees |
| |
|
|
This document updates RFC 3777, Section 3, Bullet 6 to allow aNominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. |
|
| |
| RFC 5696 | Baseline Encoding and Transport of Pre-Congestion Information |
| |
| Authors: | T. Moncaster, B. Briscoe, M. Menth. |
| Date: | November 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6660 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5696 |
|
The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging toPCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. |
|
| |
| RFC 5719 | Updated IANA Considerations for Diameter Command Code Allocations |
| |
|
|
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. |
|
| |
| RFC 5721 | POP3 Support for UTF-8 |
| |
| Authors: | R. Gellens, C. Newman. |
| Date: | February 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6856 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5721 |
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. |
|
| |
| RFC 5735 | Special Use IPv4 Addresses |
| |
|
|
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by theInternet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the RegionalInternet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional InternetRegistries. It also does not address allocations or assignments ofIPv6 addresses or autonomous system numbers. |
|
| |
| RFC 5736 | IANA IPv4 Special Purpose Address Registry |
| |
| Authors: | G. Huston, M. Cotton, L. Vegoda. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6890 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5736 |
|
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. |
|
| |
| RFC 5738 | IMAP Support for UTF-8 |
| |
|
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. |
|
| |
| RFC 5741 | RFC Streams, Headers, and Boilerplates |
| |
|
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. |
|
| |
| RFC 5750 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling |
| |
|
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.S/MIME agents validate certificates as described in RFC 5280, theInternet X.509 Public Key Infrastructure Certificate and CRL Profile.S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletesRFC 3850. |
|
| |
| RFC 5751 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification |
| |
|
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. |
|
| |
| RFC 5766 | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts(peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (TraversalUsing Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The TURN protocol was designed to be used as part of the ICE(Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. |
|
| |
| RFC 5785 | Defining Well-Known Uniform Resource Identifiers (URIs) |
| |
|
|
This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes. |
|
| |
| RFC 5787 | OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing |
| |
|
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. |
|
| |
| RFC 5798 | Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
| |
|
|
This memo defines the Virtual Router Redundancy Protocol (VRRP) forIPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in"Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to theseIPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. ForIPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6Neighbor Discovery mechanisms. |
|
| |
| RFC 5815 | Definitions of Managed Objects for IP Flow Information Export |
| |
| Authors: | T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. |
| Date: | April 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6615 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5815 |
|
This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors including the basic configuration information. |
|
| |
| RFC 5825 | Displaying Downgraded Messages for Email Address Internationalization |
| |
|
|
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. |
|
| |
| RFC 5849 | The OAuth 1.0 Protocol |
| |
|
|
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. |
|
| |
| RFC 5953 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 5966 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. |
|
| |
| RFC 5983 | Mailing Lists and Internationalized Email Addresses |
| |
|
|
This document describes considerations for mailing lists with the introduction of internationalized email addresses.
This document makes some specific recommendations on how mailing lists should act in various situations. |
|
| |
| RFC 5987 | Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters |
| |
|
|
By default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231. |
|
| |
| RFC 5988 | Web Linking |
| |
|
|
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. |
|
| |
| RFC 5996 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations(SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. |
|
| |
| RFC 6006 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. |
| Date: | September 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8306 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6006 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. |
|
| |
| RFC 6013 | TCP Cookie Transactions (TCPCT) |
| |
|
|
TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. |
|
| |
| RFC 6021 | Common YANG Data Types |
| |
| Authors: | J. Schoenwaelder, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6991 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6021 |
|
This document introduces a collection of common data types to be used with the YANG data modeling language. |
|
| |
| RFC 6036 | Emerging Service Provider Scenarios for IPv6 Deployment |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | October 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9386 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6036 |
|
This document describes practices and plans that are emerging amongInternet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. |
|
| |
| RFC 6044 | Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) |
| |
|
|
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. |
|
| |
| RFC 6045 | Real-time Inter-network Defense (RID) |
| |
|
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter- network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. |
|
| |
| RFC 6046 | Transport of Real-time Inter-network Defense (RID) Messages |
| |
| Authors: | K. Moriarty, B. Trammell. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6546 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6046 |
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). |
|
| |
| RFC 6087 | Guidelines for Authors and Reviewers of YANG Data Model Documents |
| |
|
|
This memo provides guidelines for authors and reviewers of StandardsTrack specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NetworkConfiguration Protocol (NETCONF) implementations that utilize YANG data model modules. |
|
| |
| RFC 6093 | On the Implementation of the TCP Urgent Mechanism |
| |
|
|
This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications(but provides advice to applications that do). |
|
| |
| RFC 6096 | Stream Control Transmission Protocol (SCTP) Chunk Flags Registration |
| |
|
|
This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream ControlTransmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. |
|
| |
| RFC 6106 | IPv6 Router Advertisement Options for DNS Configuration |
| |
| Authors: | J. Jeong, S. Park, L. Beloeil, S. Madanapalli. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 5006 |
| Obsoleted by: | RFC 8106 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6106 |
|
This document specifies IPv6 Router Advertisement options to allowIPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. |
|
| |
| RFC 6112 | Anonymity Support for Kerberos |
| |
|
|
This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. |
|
| |
| RFC 6122 | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
|
This document defines the format for addresses used in the ExtensibleMessaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. |
|
| |
| RFC 6125 | Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) |
| |
| Authors: | P. Saint-Andre, J. Hodges. |
| Date: | March 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6125 |
|
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509(PKIX) certificates in the context of Transport Layer Security (TLS).This document specifies procedures for representing and verifying the identity of application services in such interactions. |
|
| |
| RFC 6126 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. |
|
| |
| RFC 6145 | IP/ICMP Translation Algorithm |
| |
|
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 2765. |
|
| |
| RFC 6156 | Traversal Using Relays around NAT (TURN) Extension for IPv6 |
| |
| Authors: | G. Camarillo, O. Novo, S. Perreault, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8656 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6156 |
|
This document adds IPv6 support to Traversal Using Relays around NAT(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type theTURN server will allocate (e.g., an IPv4-only node may request theTURN server to allocate an IPv6 address). |
|
| |
| RFC 6166 | A Registry for PIM Message Types |
| |
|
|
This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types.It also specifies a procedure for registering new types.
In addition to this, one message type is reserved, and may be used for a future extension of the message type space. |
|
| |
| RFC 6170 | Internet X.509 Public Key Infrastructure -- Certificate Image |
| |
| Authors: | S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. |
| Date: | May 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9399 |
| Updates: | RFC 3709 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6170 |
|
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. |
|
| |
| RFC 6195 | Domain Name System (DNS) IANA Considerations |
| |
|
|
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 6204 | Basic Requirements for IPv6 Customer Edge Routers |
| |
| Authors: | H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7084 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6204 |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. |
|
| |
| RFC 6220 | Defining the Role and Function of IETF Protocol Parameter Registry Operators |
| |
| Authors: | D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8722 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6220 |
|
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. |
|
| |
| RFC 6222 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
|
|
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCPCNAMEs. |
|
| |
| RFC 6237 | IMAP4 Multimailbox SEARCH Extension |
| |
|
|
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields inESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. |
|
| |
| RFC 6253 | Host Identity Protocol Certificates |
| |
|
|
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies theCERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) andSimple Public Key Infrastructure (SPKI) certificates.
The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 5201. |
|
| |
| RFC 6277 | Online Certificate Status Protocol Algorithm Agility |
| |
|
|
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. |
|
| |
| RFC 6304 | AS112 Nameserver Operations |
| |
|
|
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. |
|
| |
| RFC 6312 | Mobile Networks Considerations for IPv6 Deployment |
| |
|
|
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. |
|
| |
| RFC 6326 | Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS |
| |
| Authors: | D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani. |
| Date: | July 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7176 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6326 |
|
The IETF has standardized the Transparent Interconnection of Lots ofLinks (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.This document specifies the data formats and code points for theIS-IS extensions to support TRILL. |
|
| |
| RFC 6327 | Routing Bridges (RBridges): Adjacency |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU(Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. |
|
| |
| RFC 6336 | IANA Registry for Interactive Connectivity Establishment (ICE) Options |
| |
|
|
It has been identified that "Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator (NAT) Traversal forOffer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. |
|
| |
| RFC 6347 | Datagram Transport Layer Security Version 1.2 |
| |
|
|
This document specifies version 1.2 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updatesDTLS 1.0 to work with TLS version 1.2. |
|
| |
| RFC 6424 | Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels |
| |
|
|
This document describes methods for performing LSP ping (specified inRFC 4379) traceroute over MPLS tunnels and for traceroute of stitchedMPLS Label Switched Paths (LSPs). The techniques outlined in RFC4379 are insufficient to perform traceroute Forwarding EquivalencyClass (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a newTLV that, along with other procedures outlined in this document, can be used to trace such LSPs. |
|
| |
| RFC 6429 | TCP Sender Clarification for Persist Condition |
| |
| Authors: | M. Bashyam, M. Jethanandani, A. Ramaiah. |
| Date: | December 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9293 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6429 |
|
This document clarifies the Zero Window Probes (ZWPs) described inRFC 1122 ("Requirements for Internet Hosts -- Communication Layers").In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified inRFC 1122. |
|
| |
| RFC 6434 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 4294. |
|
| |
| RFC 6439 | Routing Bridges (RBridges): Appointed Forwarders |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to IntermediateSystem) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multipleRBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called"Appointed Forwarders", with the intent that native traffic in eachVLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the AppointedForwarder mechanism; thus, it updates RFC 6325. |
|
| |
| RFC 6485 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 6486 | Manifests for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Austein, G. Huston, S. Kent, M. Lepinski. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9286 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6486 |
|
This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. |
|
| |
| RFC 6490 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7730 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6490 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). |
|
| |
| RFC 6506 | Supporting Authentication Trailer for OSPFv3 |
| |
| Authors: | M. Bhatia, V. Manral, A. Lindem. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6506 |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. |
|
| |
| RFC 6528 | Defending against Sequence Number Attacks |
| |
|
|
This document specifies an algorithm for the generation of TCPInitial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. |
|
| |
| RFC 6536 | Network Configuration Protocol (NETCONF) Access Control Model |
| |
| Authors: | A. Bierman, M. Bjorklund. |
| Date: | March 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8341 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6536 |
|
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. |
|
| |
| RFC 6548 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrativeOversight Committee (IAOC). |
|
| |
| RFC 6555 | Happy Eyeballs: Success with Dual-Stack Hosts |
| |
| Authors: | D. Wing, A. Yourtchenko. |
| Date: | April 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8305 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6555 |
|
When a server's IPv4 path and protocol are working, but the server'sIPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to anIPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. |
|
| |
| RFC 6577 | Authentication-Results Registration Update for Sender Policy Framework (SPF) Results |
| |
|
|
This memo updates the registry of authentication method results inAuthentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SenderPolicy Framework (SPF) specification.
This memo updates RFC 5451. |
|
| |
| RFC 6622 | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | U. Herberg, T. Clausen. |
| Date: | May 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6622 |
|
This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. |
|
| |
| RFC 6635 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620, and obsoletes that document. |
|
| |
| RFC 6685 | Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry |
| |
|
|
This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require ExpertReview for extensions to Incident Object Description Exchange Format(IODEF). |
|
| |
| RFC 6691 | TCP Options and Maximum Segment Size (MSS) |
| |
|
|
This memo discusses what value to use with the TCP Maximum SegmentSize (MSS) option, and updates RFC 879 and RFC 2385. |
|
| |
| RFC 6723 | Update of the Pseudowire Control-Word Negotiation Mechanism |
| |
|
|
The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. |
|
| |
| RFC 6732 | 6to4 Provider Managed Tunnels |
| |
| Authors: | V. Kuarsingh, Ed., Y. Lee, O. Vautrin. |
| Date: | September 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7526 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6732 |
|
6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. |
|
| |
| RFC 6779 | Definition of Managed Objects for the Neighborhood Discovery Protocol |
| |
| Authors: | U. Herberg, R. Cole, I. Chakeres. |
| Date: | October 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7939 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6779 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. |
|
| |
| RFC 6822 | IS-IS Multi-Instance |
| |
| Authors: | S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. |
| Date: | December 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8202 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6822 |
|
This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs. |
|
| |
| RFC 6824 | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8684 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6824 |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. |
|
| |
| RFC 6829 | Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 |
| |
|
|
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.
This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6LDP sessions. This document updates RFC 4379. |
|
| |
| RFC 6830 | The Locator/ID Separation Protocol (LISP) |
| |
|
|
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop. |
|
| |
| RFC 6833 | Locator/ID Separation Protocol (LISP) Map-Server Interface |
| |
| Authors: | V. Fuller, D. Farinacci. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9301 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6833 |
|
This document describes the Mapping Service for the Locator/IDSeparation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID toRouting Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress TunnelRouters are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs.Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. |
|
| |
| RFC 6834 | Locator/ID Separation Protocol (LISP) Map-Versioning |
| |
| Authors: | L. Iannone, D. Saucez, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9302 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6834 |
|
This document describes the LISP (Locator/ID Separation Protocol)Map-Versioning mechanism, which provides in-packet information aboutEndpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header ofLISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. |
|
| |
| RFC 6844 | DNS Certification Authority Authorization (CAA) Resource Record |
| |
| Authors: | P. Hallam-Baker, R. Stradling. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8659 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6844 |
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain.CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. |
|
| |
| RFC 6859 | Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership |
| |
|
|
RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative OversightCommittee (IAOC) was formed; that body is not covered by RFC 3777.There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of theIAB, the IESG, and the IAOC. |
|
| |
| RFC 6931 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. |
|
| |
| RFC 6944 | Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status |
| |
|
|
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures overDNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. |
|
| |
| RFC 6961 | The Transport Layer Security (TLS) Multiple Certificate Status Request Extension |
| |
|
|
This document defines the Transport Layer Security (TLS) CertificateStatus Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the CertificateStatus extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate StatusProtocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain. |
|
| |
| RFC 6962 | Certificate Transparency |
| |
| Authors: | B. Laurie, A. Langley, E. Kasper. |
| Date: | June 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9162 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6962 |
|
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcingCAs to add all issued certificates to the logs.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. |
|
| |
| RFC 6982 | Improving Awareness of Running Code: The Implementation Status Section |
| |
|
|
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
The process in this document is offered as an experiment. Authors ofInternet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. |
|
| |
| RFC 7001 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7042 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. |
|
| |
| RFC 7049 | Concise Binary Object Representation (CBOR) |
| |
| Authors: | C. Bormann, P. Hoffman. |
| Date: | October 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7049 |
|
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. |
|
| |
| RFC 7053 | SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol |
| |
|
|
This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SelectiveAcknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. |
|
| |
| RFC 7083 | Modification to Default Values of SOL_MAX_RT and INF_MAX_RT |
| |
|
|
This document updates RFC 3315 by redefining the default values forSOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT andINF_MAX_RT with new values. |
|
| |
| RFC 7125 | Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element |
| |
| Authors: | B. Trammell, P. Aitken. |
| Date: | February 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9565 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7125 |
|
This document revises the tcpControlBits IP Flow Information Export(IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. |
|
| |
| RFC 7150 | Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol |
| |
| Authors: | F. Zhang, A. Farrel. |
| Date: | March 2014 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7470 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7150 |
|
The Path Computation Element communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object. |
|
| |
| RFC 7158 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7159 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7180 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic.TRILL accomplishes this by using Intermediate System to IntermediateSystem (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439. |
|
| |
| RFC 7223 | A YANG Data Model for Interface Management |
| |
|
|
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes configuration data and state data (status information and counters for the collection of statistics). |
|
| |
| RFC 7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" UniformResource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. |
|
| |
| RFC 7231 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. |
|
| |
| RFC 7232 | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. |
|
| |
| RFC 7233 | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| |
| Authors: | R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7233 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests. |
|
| |
| RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9111 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7234 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. |
|
| |
| RFC 7235 | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. |
|
| |
| RFC 7238 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7248 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | May 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8048 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7248 |
|
This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). |
|
| |
| RFC 7277 | A YANG Data Model for IP Management |
| |
|
|
This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data. |
|
| |
| RFC 7283 | Handling Unknown DHCPv6 Messages |
| |
|
|
DHCPv6 is not specific about handling messages with unknown types.This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages.This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315. |
|
| |
| RFC 7298 | Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication |
| |
|
|
This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible. |
|
| |
| RFC 7302 | Entertainment Identifier Registry (EIDR) URN Namespace Definition |
| |
|
|
Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers. |
|
| |
| RFC 7320 | URI Design and Ownership |
| |
|
|
Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. |
|
| |
| RFC 7321 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
This document updates the Cryptographic Algorithm ImplementationRequirements for the Encapsulating Security Payload (ESP) andAuthentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.
ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.
This document obsoletes RFC 4835. |
|
| |
| RFC 7329 | A Session Identifier for the Session Initiation Protocol (SIP) |
| |
|
|
There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIPProxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.
The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a newStandards Track document produced by the INSIPID Working Group. |
|
| |
| RFC 7386 | JSON Merge Patch |
| |
| Authors: | P. Hoffman, J. Snell. |
| Date: | October 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7396 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7386 |
|
This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content. |
|
| |
| RFC 7410 | A Property Types Registry for the Authentication-Results Header Field |
| |
|
|
This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. |
|
| |
| RFC 7437 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 7482 | Registration Data Access Protocol (RDAP) Query Format |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9082 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7482 |
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP). |
|
| |
| RFC 7483 | JSON Responses for the Registration Data Access Protocol (RDAP) |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9083 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7483 |
|
This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. |
|
| |
| RFC 7484 | Finding the Authoritative Registration Data (RDAP) Service |
| |
|
|
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers. |
|
| |
| RFC 7500 | Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries |
| |
| Authors: | R. Housley, Ed., O. Kolkman, Ed.. |
| Date: | April 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8720 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7500 |
|
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries. |
|
| |
| RFC 7507 | TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks |
| |
|
|
This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security(TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included. |
|
| |
| RFC 7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS.The recommendations are applicable to the majority of use cases. |
|
| |
| RFC 7537 | IANA Registries for LSP Ping Code Points |
| |
|
|
RFCs 4379 and 6424 created name spaces for Multi-Protocol LabelSwitching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for DownstreamMapping object Flags (DS Flags), Multipath Types, Pad TLVs, andInterface and Label Stack Address Types.
There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose. |
|
| |
| RFC 7538 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7539 | ChaCha20 and Poly1305 for IETF Protocols |
| |
|
|
This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data(AEAD) algorithm.
This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). |
|
| |
| RFC 7540 | Hypertext Transfer Protocol Version 2 (HTTP/2) |
| |
|
|
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, theHTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. |
|
| |
| RFC 7550 | Issues and Recommendations with Multiple Stateful DHCPv6 Options |
| |
|
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options.DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues. |
|
| |
| RFC 7557 | Extension Mechanism for the Babel Routing Protocol |
| |
|
|
This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126. |
|
| |
| RFC 7564 | PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols |
| |
|
|
Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 3454. |
|
| |
| RFC 7601 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7613 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords |
| |
|
|
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC3454, and this document obsoletes RFC 4013. |
|
| |
| RFC 7615 | HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields |
| |
|
|
This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HypertextTransfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted. |
|
| |
| RFC 7626 | DNS Privacy Considerations |
| |
|
|
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. |
|
| |
| RFC 7630 | HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 |
| |
| Authors: | J. Merkle, Ed., M. Lochter. |
| Date: | October 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7860 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7630 |
|
This memo specifies new HMAC-SHA-2 authentication protocols for theUser-based Security Model (USM) for SNMPv3 defined in RFC 3414. |
|
| |
| RFC 7674 | Clarification of the Flowspec Redirect Extended Community |
| |
|
|
This document updates RFC 5575 ("Dissemination of Flow SpecificationRules") to clarify the formatting of the BGP Flowspec RedirectExtended Community. |
|
| |
| RFC 7691 | Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members |
| |
|
|
BCP 101 defines the start and end dates for the terms of IETFAdministrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct theIAOC to establish more practical start and end dates for terms ofIAOC members. |
|
| |
| RFC 7694 | Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding |
| |
|
|
In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests. |
|
| |
| RFC 7700 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames |
| |
|
|
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. |
|
| |
| RFC 7706 | Decreasing Access Time to Root Servers by Running One on Loopback |
| |
| Authors: | W. Kumari, P. Hoffman. |
| Date: | November 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8806 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7706 |
|
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. |
|
| |
| RFC 7710 | Captive-Portal Identification Using DHCP or Router Advertisements (RAs) |
| |
| Authors: | W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8910 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7710 |
|
In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement(RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to getInternet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document. |
|
| |
| RFC 7719 | DNS Terminology |
| |
| Authors: | P. Hoffman, A. Sullivan, K. Fujiwara. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8499 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7719 |
|
The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. |
|
| |
| RFC 7730 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | January 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 6490 |
| Obsoleted by: | RFC 8630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7730 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. |
|
| |
| RFC 7749 | The "xml2rfc" Version 2 Vocabulary |
| |
|
|
This document defines the "xml2rfc" version 2 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts.
Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
This document obsoletes RFC 2629. |
|
| |
| RFC 7752 | North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP |
| |
| Authors: | H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. |
| Date: | March 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9552 |
| Updated by: | RFC 9029 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7752 |
|
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs). |
|
| |
| RFC 7807 | Problem Details for HTTP APIs |
| |
| Authors: | M. Nottingham, E. Wilde. |
| Date: | March 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9457 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7807 |
|
This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. |
|
| |
| RFC 7810 | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. |
| Date: | May 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8570 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7810 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. |
|
| |
| RFC 7816 | DNS Query Name Minimisation to Improve Privacy |
| |
|
|
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. |
|
| |
| RFC 7895 | YANG Module Library |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | June 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7895 |
|
This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. |
|
| |
| RFC 8022 | A YANG Data Model for Routing Management |
| |
| Authors: | L. Lhotka, A. Lindem. |
| Date: | November 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8349 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8022 |
|
This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes,Routing Information Bases (RIBs), and control-plane protocols. |
|
| |
| RFC 8049 | YANG Data Model for L3VPN Service Delivery |
| |
| Authors: | S. Litkowski, L. Tomotaki, K. Ogaki. |
| Date: | February 2017 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8299 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8049 |
|
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. |
|
| |
| RFC 8113 | Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations |
| |
|
|
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830. |
|
| |
| RFC 8152 | CBOR Object Signing and Encryption (COSE) |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format.This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. |
|
| |
| RFC 8203 | BGP Administrative Shutdown Communication |
| |
|
|
This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. |
|
| |
| RFC 8208 | BGPsec Algorithms, Key Formats, and Signature Formats |
| |
|
|
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. |
|
| |
| RFC 8229 | TCP Encapsulation of IKE and IPsec Packets |
| |
| Authors: | T. Pauly, S. Touati, R. Mantha. |
| Date: | August 2017 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9329 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8229 |
|
This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. |
|
| |
| RFC 8312 | CUBIC for Fast Long-Distance Networks |
| |
| Authors: | I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9438 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8312 |
|
CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC. |
|
| |
| RFC 8318 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 8321 | Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. |
| Date: | January 2018 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9341 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8321 |
|
This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on anAlternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application. |
|
| |
| RFC 8399 | Internationalization Updates to RFC 5280 |
| |
|
|
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates. |
|
| |
| RFC 8478 | Zstandard Compression and the application/zstd Media Type |
| |
| Authors: | Y. Collet, M. Kucherawy, Ed.. |
| Date: | October 2018 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8878 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8478 |
|
Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet MailExtensions (MIME).
Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. |
|
| |
| RFC 8499 | DNS Terminology |
| |
|
|
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in theDNS in a single document.
This document obsoletes RFC 7719 and updates RFC 2308. |
|
| |
| RFC 8540 | Stream Control Transmission Protocol: Errata and Issues in RFC 4960 |
| |
| Authors: | R. Stewart, M. Tuexen, M. Proshin. |
| Date: | February 2019 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8540 |
|
This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided. |
|
| |
| RFC 8728 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity(IASA) and related structures with those defined by the IASA 2.0Model. |
|
| |
| RFC 8736 | PIM Message Type Space Extension and Reserved Bits |
| |
|
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.
This document obsoletes RFC 6166. |
|
| |
| RFC 8740 | Using TLS 1.3 with HTTP/2 |
| |
|
|
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction. |
|
| |
| RFC 8782 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification |
| |
| Authors: | T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague. |
| Date: | May 2020 |
| Formats: | txt pdf xml json html |
| Obsoleted by: | RFC 9132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8782 |
|
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. |
|
| |
| RFC 8788 | Eligibility for the 2020-2021 Nominating Committee |
| |
|
|
The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in- person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future. |
|
| |
| RFC 8829 | JavaScript Session Establishment Protocol (JSEP) |
| |
| Authors: | J. Uberti, C. Jennings, E. Rescorla, Ed.. |
| Date: | January 2021 |
| Formats: | txt xml json pdf html |
| Obsoleted by: | RFC 9429 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8829 |
|
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. |
|
| |
| RFC 8843 | Negotiating Media Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941. |
|
| |
| RFC 8889 | Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto. |
| Date: | August 2020 |
| Formats: | txt html pdf xml json |
| Obsoleted by: | RFC 9342 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8889 |
|
The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking". |
|
| |
| RFC 8919 | IS-IS Application-Specific Link Attributes |
| |
| Authors: | L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. |
| Date: | October 2020 |
| Formats: | txt html json xml pdf |
| Obsoleted by: | RFC 9479 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8919 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. |
|
| |
| RFC 8920 | OSPF Application-Specific Link Attributes |
| |
| Authors: | P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. |
| Date: | October 2020 |
| Formats: | txt pdf xml html json |
| Obsoleted by: | RFC 9492 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8920 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings. |
|
| |
| RFC 8989 | Additional Criteria for Nominating Committee Eligibility |
| |
|
|
This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713. |
|
| |
| RFC 9029 | Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries |
| |
|
|
RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).IANA created a registry consistent with that document called "BorderGateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.
This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts. |
|
