Internet Documents

RFCs

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 10 Documentation conventions
 
Authors:S.D. Crocker.
Date:July 1969
Formats:txt pdf
Obsoletes:RFC 0003
Obsoleted by:RFC 0016
Updated by:RFC 0024, RFC 0027, RFC 0030
Status:UNKNOWN
DOI:10.17487/RFC 0010
 
 
RFC 16 M.I.T
 
Authors:S. Crocker.
Date:August 1969
Formats:txt pdf
Obsoletes:RFC 0010
Obsoleted by:RFC 0024
Updated by:RFC 0024, RFC 0027, RFC 0030
Status:UNKNOWN
DOI:10.17487/RFC 0016
 
 
RFC 24 Documentation Conventions
 
Authors:S.D. Crocker.
Date:November 1969
Formats:txt pdf
Obsoletes:RFC 0016
Updates:RFC 0010, RFC 0016
Updated by:RFC 0027, RFC 0030
Status:UNKNOWN
DOI:10.17487/RFC 0024
 
 
RFC 27 Documentation Conventions
 
Authors:S.D. Crocker.
Date:December 1969
Formats:txt pdf
Updates:RFC 0010, RFC 0016, RFC 0024
Updated by:RFC 0030
Status:UNKNOWN
DOI:10.17487/RFC 0027
 
 
RFC 33 New Host-Host Protocol
 
Authors:S.D. Crocker.
Date:February 1970
Formats:txt pdf
Obsoletes:RFC 0011
Updated by:RFC 0036, RFC 0047
Status:UNKNOWN
DOI:10.17487/RFC 0033
 
 
RFC 36 Protocol Notes
 
Authors:S.D. Crocker.
Date:March 1970
Formats:txt pdf
Updates:RFC 0033
Updated by:RFC 0039, RFC 0044
Status:UNKNOWN
DOI:10.17487/RFC 0036
 
 
RFC 52 Updated distribution list
 
Authors:J. Postel, S.D. Crocker.
Date:July 1970
Formats:txt pdf
Updated by:RFC 0069
Status:UNKNOWN
DOI:10.17487/RFC 0052
 
 
RFC 54 Official Protocol Proffering
 
Authors:S.D. Crocker, J. Postel, J. Newkirk, M. Kraley.
Date:June 1970
Formats:txt pdf
Updated by:RFC 0057
Status:UNKNOWN
DOI:10.17487/RFC 0054
 
 
RFC 66 NIC - third level ideas and other noise
 
Authors:S.D. Crocker.
Date:August 1970
Formats:txt pdf
Obsoleted by:RFC 0123
Updated by:RFC 0080, RFC 0093
Status:UNKNOWN
DOI:10.17487/RFC 0066
 
 
RFC 70 Note on Padding
 
Authors:S.D. Crocker.
Date:October 1970
Formats:txt pdf
Updated by:RFC 0228
Status:UNKNOWN
DOI:10.17487/RFC 0070
 
 
RFC 74 Specifications for Network Use of the UCSB On-Line System
 
Authors:J.E. White.
Date:October 1970
Formats:txt pdf
Updated by:RFC 0217, RFC 0225
Status:UNKNOWN
DOI:10.17487/RFC 0074
 
 
RFC 80 Protocols and Data Formats
 
Authors:E. Harslem, J.F. Heafner.
Date:December 1970
Formats:txt pdf
Obsoleted by:RFC 0123
Updates:RFC 0066
Updated by:RFC 0093
Status:UNKNOWN
DOI:10.17487/RFC 0080
 
 
RFC 86 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display
 
Authors:S.D. Crocker.
Date:January 1971
Formats:txt pdf
Updated by:RFC 0125
Status:UNKNOWN
DOI:10.17487/RFC 0086
 
 
RFC 98 Logger Protocol Proposal
 
Authors:E. Meyer, T. Skinner.
Date:February 1971
Formats:txt pdf
Updated by:RFC 0123
Status:UNKNOWN
DOI:10.17487/RFC 0098
 
 
RFC 99 Network Meeting
 
Authors:P.M. Karp.
Date:February 1971
Formats:txt pdf
Updated by:RFC 0116
Status:UNKNOWN
DOI:10.17487/RFC 0099
 
 
RFC 101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971
 
Authors:R.W. Watson.
Date:February 1971
Formats:txt pdf
Updated by:RFC 0108, RFC 0123
Status:UNKNOWN
DOI:10.17487/RFC 0101
 
 
RFC 102 Output of the Host-Host Protocol glitch cleaning committee
 
Authors:S.D. Crocker.
Date:February 1971
Formats:txt pdf
Updated by:RFC 0107
Status:UNKNOWN
DOI:10.17487/RFC 0102
 
 
RFC 105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB
 
Authors:J.E. White.
Date:March 1971
Formats:txt pdf
Updated by:RFC 0217
Status:UNKNOWN
DOI:10.17487/RFC 0105
 
 
RFC 107 Output of the Host-Host Protocol Glitch Cleaning Committee
 
Authors:R.D. Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson, J.E. White.
Date:March 1971
Formats:txt pdf
Updates:RFC 0102
Updated by:RFC 0111, RFC 0124, RFC 0132, RFC 0154, RFC 0179
Status:UNKNOWN
DOI:10.17487/RFC 0107
 
 
RFC 110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts
 
Authors:J. Winett.
Date:March 1971
Formats:txt pdf
Updated by:RFC 0135
Status:UNKNOWN
DOI:10.17487/RFC 0110
 
 
RFC 111 Pressure from the Chairman
 
Authors:S.D. Crocker.
Date:March 1971
Formats:txt pdf
Updates:RFC 0107
Updated by:RFC 0130
Status:UNKNOWN
DOI:10.17487/RFC 0111
 
 
RFC 113 Network activity report: UCSB Rand
 
Authors:E. Harslem, J.F. Heafner, J.E. White.
Date:April 1971
Formats:txt pdf
Updated by:RFC 0227
Status:UNKNOWN
DOI:10.17487/RFC 0113
 
 
RFC 114 File Transfer Protocol
 
Authors:A.K. Bhushan.
Date:April 1971
Formats:txt pdf
Updated by:RFC 0133, RFC 0141, RFC 0171, RFC 0172
Status:UNKNOWN
DOI:10.17487/RFC 0114
 
 
RFC 116 Structure of the May NWG Meeting
 
Authors:S.D. Crocker.
Date:April 1971
Formats:txt pdf
Updates:RFC 0099
Updated by:RFC 0131, RFC 0156
Status:UNKNOWN
DOI:10.17487/RFC 0116
 
 
RFC 122 Network specifications for UCSB's Simple-Minded File System
 
Authors:J.E. White.
Date:April 1971
Formats:txt pdf
Updated by:RFC 0217, RFC 0269, RFC 0399, RFC 0431
Status:UNKNOWN
DOI:10.17487/RFC 0122
 
 
RFC 123 Proffered Official ICP
 
Authors:S.D. Crocker.
Date:April 1971
Formats:txt pdf
Obsoletes:RFC 0066, RFC 0080
Obsoleted by:RFC 0165
Updates:RFC 0098, RFC 0101
Updated by:RFC 0127, RFC 0143, RFC 0148
Status:UNKNOWN
DOI:10.17487/RFC 0123
 
 
RFC 125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream
 
Authors:J. McConnell.
Date:April 1971
Formats:txt pdf
Updates:RFC 0086
Updated by:RFC 0177
Status:UNKNOWN
DOI:10.17487/RFC 0125
 
 
RFC 127 Comments on RFC 123
 
Authors:J. Postel.
Date:April 1971
Formats:txt pdf
Obsoleted by:RFC 0145
Updates:RFC 0123
Updated by:RFC 0151
Status:UNKNOWN
DOI:10.17487/RFC 0127
 
 
RFC 129 Request for comments on socket name structure
 
Authors:E. Harslem, J. Heafner, E. Meyer.
Date:April 1971
Formats:txt pdf
Updated by:RFC 0147
Status:UNKNOWN
DOI:10.17487/RFC 0129
 
 
RFC 137 Telnet Protocol - a proposed document
 
Authors:T.C. O'Sullivan.
Date:April 1971
Formats:txt pdf
Updated by:RFC 0139
Status:UNKNOWN
DOI:10.17487/RFC 0137
 
 
RFC 139 Discussion of Telnet Protocol
 
Authors:T.C. O'Sullivan.
Date:May 1971
Formats:txt pdf
Updates:RFC 0137
Updated by:RFC 0158
Also:RFC 0393
Status:UNKNOWN
DOI:10.17487/RFC 0139
 
 
RFC 140 Agenda for the May NWG meeting
 
Authors:S.D. Crocker.
Date:May 1971
Formats:txt pdf
Updated by:RFC 0149
Status:UNKNOWN
DOI:10.17487/RFC 0140
 
 
RFC 145 Initial Connection Protocol Control Commands
 
Authors:J. Postel.
Date:May 1971
Formats:txt ps pdf
Obsoletes:RFC 0127
Obsoleted by:RFC 0165
Updated by:RFC 0143
Status:UNKNOWN
DOI:10.17487/RFC 0145
 
 
RFC 158 Telnet Protocol: A Proposed Document
 
Authors:T.C. O'Sullivan.
Date:May 1971
Formats:txt pdf
Obsoleted by:RFC 0495
Updates:RFC 0139
Updated by:RFC 0318
Also:RFC 0393
Status:UNKNOWN
DOI:10.17487/RFC 0158
 
 
RFC 165 Proffered Official Initial Connection Protocol
 
Authors:J. Postel.
Date:May 1971
Formats:txt pdf
Obsoletes:RFC 0145, RFC 0143, RFC 0123
Updated by:NIC_7101
Status:UNKNOWN
DOI:10.17487/RFC 0165
 
 
RFC 171 The Data Transfer Protocol
 
Authors:A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White.
Date:June 1971
Formats:txt pdf
Obsoleted by:RFC 0264
Updates:RFC 0114
Updated by:RFC 0238
Status:UNKNOWN
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 pdf
Obsoleted by:RFC 0265
Updates:RFC 0114
Updated by:RFC 0238
Status:UNKNOWN
DOI:10.17487/RFC 0172
 
 
RFC 177 Device independent graphical display description
 
Authors:J. McConnell.
Date:June 1971
Formats:txt pdf
Updates:RFC 0125
Updated by:RFC 0181
Status:UNKNOWN
DOI:10.17487/RFC 0177
 
 
RFC 189 Interim NETRJS specifications
 
Authors:R.T. Braden.
Date:July 1971
Formats:txt pdf
Obsoletes:RFC 0088
Obsoleted by:RFC 0599
Updated by:RFC 0283
Status:UNKNOWN
DOI:10.17487/RFC 0189
 
 
RFC 193 NETWORK CHECKOUT
 
Authors:E. Harslem, J.F. Heafner.
Date:July 1971
Formats:txt pdf
Obsoleted by:RFC 0198
Updated by:RFC 0198
Status:UNKNOWN
DOI:10.17487/RFC 0193
 
 
RFC 204 Sockets in use
 
Authors:J. Postel.
Date:August 1971
Formats:txt pdf
Updated by:RFC 0234
Status:UNKNOWN
DOI:10.17487/RFC 0204
 
 
RFC 212 NWG meeting on network usage
 
Authors:Information Sciences Institute University of Southern California.
Date:August 1971
Formats:txt pdf
Obsoletes:RFC 0207
Updated by:RFC 0222
Status:UNKNOWN
DOI:10.17487/RFC 0212
 
 
RFC 222 Subject: System programmer's workshop
 
Authors:R.M. Metcalfe.
Date:September 1971
Formats:txt pdf
Updates:RFC 0212
Updated by:RFC 0234
Status:UNKNOWN
DOI:10.17487/RFC 0222
 
 
RFC 264 The Data Transfer Protocol
 
Authors:A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White.
Date:January 1972
Formats:txt pdf
Obsoletes:RFC 0171
Obsoleted by:RFC 0354
Updated by:RFC 0310
Also:RFC 0265
Status:UNKNOWN
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 pdf
Obsoletes:RFC 0172
Obsoleted by:RFC 0354
Updated by:RFC 0281, RFC 0294, RFC 0310
Also:RFC 0264
Status:UNKNOWN
DOI:10.17487/RFC 0265
 
 
RFC 288 Network host status
 
Authors:E. Westheimer.
Date:January 1972
Formats:txt pdf
Obsoletes:RFC 0287
Obsoleted by:RFC 0293
Updated by:RFC 0293
Status:UNKNOWN
DOI:10.17487/RFC 0288
 
 
RFC 318 Telnet Protocols
 
Authors:J. Postel.
Date:April 1972
Formats:txt pdf
Updates:RFC 0158
Updated by:RFC 0435
Also:RFC 0139, RFC 0158
Status:UNKNOWN
DOI:10.17487/RFC 0318
 
 
RFC 319 Network Host Status
 
Authors:E. Westheimer.
Date:March 1972
Formats:txt pdf
Obsoletes:RFC 0315
Updated by:RFC 0326
Status:UNKNOWN
DOI:10.17487/RFC 0319
 
 
RFC 323 Formation of Network Measurement Group (NMG)
 
Authors:V. Cerf.
Date:March 1972
Formats:txt pdf
Updated by:RFC 0388
Status:UNKNOWN
DOI:10.17487/RFC 0323
 
 
RFC 330 Network Host Status
 
Authors:E. Westheimer.
Date:April 1972
Formats:txt pdf
Obsoletes:RFC 0326
Updated by:RFC 0332
Status:UNKNOWN
DOI:10.17487/RFC 0330
 
 
RFC 354 File Transfer Protocol
 
Authors:A.K. Bhushan.
Date:July 1972
Formats:txt pdf
Obsoletes:RFC 0264, RFC 0265
Obsoleted by:RFC 0542
Updated by:RFC 0385, RFC 0454, RFC 0683
Status:UNKNOWN
DOI:10.17487/RFC 0354
 
 
RFC 370 Network Host Status
 
Authors:E. Westheimer.
Date:July 1972
Formats:txt pdf
Obsoletes:RFC 0367
Updated by:RFC 0376
Status:UNKNOWN
DOI:10.17487/RFC 0370
 
 
RFC 381 Three aids to improved network operation
 
Authors:J.M. McQuillan.
Date:July 1972
Formats:txt pdf
Updated by:RFC 0394
Status:UNKNOWN
DOI:10.17487/RFC 0381
 
 
RFC 385 Comments on the File Transfer Protocol
 
Authors:A.K. Bhushan.
Date:August 1972
Formats:txt pdf
Updates:RFC 0354
Updated by:RFC 0414
Status:UNKNOWN
DOI:10.17487/RFC 0385
 
 
RFC 387 Some experiences in implementing Network Graphics Protocol Level 0
 
Authors:K.C. Kelley, J. Meir.
Date:August 1972
Formats:txt pdf
Updated by:RFC 0401
Status:UNKNOWN
DOI:10.17487/RFC 0387
 
 
RFC 396 Network Graphics Working Group Meeting - Second Iteration
 
Authors:S. Bunch.
Date:November 1972
Formats:txt pdf
Updated by:RFC 0474
Status:UNKNOWN
DOI:10.17487/RFC 0396
 
 
RFC 404 Host Address Changes Involving Rand and ISI
 
Authors:A.M. McKenzie.
Date:October 1972
Formats:txt pdf
Updated by:RFC 0405
Status:UNKNOWN
DOI:10.17487/RFC 0404
 
 
RFC 442 Current flow-control scheme for IMPSYS
 
Authors:V. Cerf.
Date:January 1973
Formats:txt pdf
Updated by:RFC 0449
Status:UNKNOWN
DOI:10.17487/RFC 0442
 
 
RFC 467 Proposed change to Host-Host Protocol: Resynchronization of connection status
 
Authors:J.D. Burchfiel, R.S. Tomlinson.
Date:February 1973
Formats:txt pdf
Updated by:RFC 0492
Status:UNKNOWN
DOI:10.17487/RFC 0467
 
 
RFC 482 Traffic statistics (February 1973)
 
Authors:A.M. McKenzie.
Date:March 1973
Formats:txt pdf
Updated by:RFC 0497
Status:UNKNOWN
DOI:10.17487/RFC 0482
 
 
RFC 495 Telnet Protocol specifications
 
Authors:A.M. McKenzie.
Date:May 1973
Formats:txt pdf
Obsoletes:RFC 0158
Updated by:RFC 0562
Status:UNKNOWN
DOI:10.17487/RFC 0495
 
 
RFC 538 Traffic statistics (June 1973)
 
Authors:A.M. McKenzie.
Date:July 1973
Formats:txt pdf
Updated by:RFC 0556
Status:UNKNOWN
DOI:10.17487/RFC 0538
 
 
RFC 542 File Transfer Protocol
 
Authors:N. Neigus.
Date:August 1973
Formats:txt pdf
Obsoletes:RFC 0354
Obsoleted by:RFC 0765
Updated by:RFC 0614, RFC 0640
Also:RFC 0454, RFC 0495
Status:UNKNOWN
DOI:10.17487/RFC 0542
 
 
RFC 560 Remote Controlled Transmission and Echoing Telnet option
 
Authors:D. Crocker, J. Postel.
Date:August 1973
Formats:txt pdf
Updated by:RFC 0581
Status:UNKNOWN
DOI:10.17487/RFC 0560
 
 
RFC 561 Standardizing Network Mail Headers
 
Authors:A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White.
Date:September 1973
Formats:txt pdf
Updated by:RFC 0680
Status:UNKNOWN
DOI:10.17487/RFC 0561
 
 
RFC 566 Traffic statistics (August 1973)
 
Authors:A.M. McKenzie.
Date:September 1973
Formats:txt pdf
Updated by:RFC 0579
Status:UNKNOWN
DOI:10.17487/RFC 0566
 
 
RFC 567 Cross Country Network Bandwidth
 
Authors:L.P. Deutsch.
Date:September 1973
Formats:txt pdf
Updated by:RFC 0568
Status:UNKNOWN
DOI:10.17487/RFC 0567
 
 
RFC 579 Traffic statistics (September 1973)
 
Authors:A.M. McKenzie.
Date:November 1973
Formats:txt pdf
Updates:RFC 0566
Updated by:RFC 0586
Status:UNKNOWN
DOI:10.17487/RFC 0579
 
 
RFC 580 Note to Protocol Designers and Implementers
 
Authors:J. Postel.
Date:October 1973
Formats:txt pdf
Updated by:RFC 0582
Status:UNKNOWN
DOI:10.17487/RFC 0580
 
 
RFC 597 Host status
 
Authors:N. Neigus, E.J. Feinler.
Date:December 1973
Formats:txt pdf
Updated by:RFC 0603
Status:UNKNOWN
DOI:10.17487/RFC 0597
 
 
RFC 603 Response to RFC 597: Host status
 
Authors:J.D. Burchfiel.
Date:December 1973
Formats:txt pdf
Updates:RFC 0597
Updated by:RFC 0613
Status:UNKNOWN
DOI:10.17487/RFC 0603
Questions about the ARPANET topology described in RFC 597.
 
RFC 607 Comments on the File Transfer Protocol
 
Authors:M. Krilanovich, G. Gregg.
Date:January 1974
Formats:txt pdf
Obsoleted by:RFC 0624
Updated by:RFC 0614
Status:UNKNOWN
DOI:10.17487/RFC 0607
An old version; see RFC 624; see also RFCs 614, 542 and 640.
 
RFC 661 Protocol information
 
Authors:J. Postel.
Date:November 1974
Formats:txt pdf
Updated by:RFC 0694
Status:UNKNOWN
DOI:10.17487/RFC 0661
 
 
RFC 669 November, 1974, survey of New-Protocol Telnet servers
 
Authors:D.W. Dodds.
Date:December 1974
Formats:txt pdf
Updates:RFC 0702
Updated by:RFC 0679
Status:UNKNOWN
DOI:10.17487/RFC 0669
An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.
 
RFC 679 February, 1975, survey of New-Protocol Telnet servers
 
Authors:D.W. Dodds.
Date:February 1975
Formats:txt pdf
Updates:RFC 0669
Updated by:RFC 0703
Status:UNKNOWN
DOI:10.17487/RFC 0679
 
 
RFC 687 IMP/Host and Host/IMP Protocol changes
 
Authors:D.C. Walden.
Date:June 1975
Formats:txt pdf
Obsoleted by:RFC 0704
Updated by:RFC 0690
Status:UNKNOWN
DOI:10.17487/RFC 0687
Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.
 
RFC 690 Comments on the proposed Host/IMP Protocol changes
 
Authors:J. Postel.
Date:June 1975
Formats:txt pdf
Updates:RFC 0687
Updated by:RFC 0692
Status:UNKNOWN
DOI:10.17487/RFC 0690
Comments on suggestions in RFC 687; see also RFCs 692 and 696.
 
RFC 701 August, 1974, survey of New-Protocol Telnet servers
 
Authors:D.W. Dodds.
Date:August 1974
Formats:txt pdf
Updated by:RFC 0702
Status:UNKNOWN
DOI:10.17487/RFC 0701
 
 
RFC 702 September, 1974, survey of New-Protocol Telnet servers
 
Authors:D.W. Dodds.
Date:September 1974
Formats:txt pdf
Updates:RFC 0701
Updated by:RFC 0669
Status:UNKNOWN
DOI:10.17487/RFC 0702
 
 
RFC 732 Telnet Data Entry Terminal option
 
Authors:J.D. Day.
Date:September 1977
Formats:txt pdf
Obsoletes:RFC 0731
Updated by:RFC 1043
Status:UNKNOWN
DOI:10.17487/RFC 0732
 
 
RFC 760 DoD standard Internet Protocol
 
Authors:J. Postel.
Date:January 1980
Formats:txt pdf
Obsoletes:IEN123
Obsoleted by:RFC 0791
Updated by:RFC 0777
Status:UNKNOWN
DOI:10.17487/RFC 0760
 
 
RFC 791 Internet Protocol
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Obsoletes:RFC 0760
Updated by:RFC 1349, RFC 2474, RFC 6864
Also:STD 0005
Status:INTERNET STANDARD
DOI:10.17487/RFC 0791
 
 
RFC 792 Internet Control Message Protocol
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Obsoletes:RFC 0777
Updated by:RFC 0950, RFC 4884, RFC 6633, RFC 6918
Also:STD 0005
Status:INTERNET STANDARD
DOI:10.17487/RFC 0792
 
 
RFC 793 Transmission Control Protocol
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Obsoletes:RFC 0761
Updated by:RFC 1122, RFC 3168, RFC 6093, RFC 6528
Also:STD 0007
Status:INTERNET STANDARD
DOI:10.17487/RFC 0793
 
 
RFC 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
 
Authors:D. Crocker.
Date:August 1982
Formats:txt pdf
Obsoletes:RFC 0733
Obsoleted by:RFC 2822
Updated by:RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148
Also:STD 0011
Status:INTERNET STANDARD
DOI:10.17487/RFC 0822
This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.
 
RFC 826 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
 
Authors:D. Plummer.
Date:November 1982
Formats:txt pdf
Updated by:RFC 5227, RFC 5494
Also:STD 0037
Status:INTERNET STANDARD
DOI:10.17487/RFC 0826
The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.
 
RFC 827 Exterior Gateway Protocol (EGP)
 
Authors:E.C. Rosen.
Date:October 1982
Formats:txt pdf
Updated by:RFC 0904
Status:UNKNOWN
DOI:10.17487/RFC 0827
This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.
 
RFC 843 Who talks TCP? - survey of 8 February 83
 
Authors:D. Smallberg.
Date:February 1983
Formats:txt pdf
Obsoletes:RFC 0842
Obsoleted by:RFC 0845
Updated by:RFC 0844
Status:UNKNOWN
DOI:10.17487/RFC 0843
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.
 
RFC 854 Telnet Protocol Specification
 
Authors:J. Postel, J.K. Reynolds.
Date:May 1983
Formats:txt pdf
Obsoletes:RFC 0764
Updated by:RFC 5198
Also:STD 0008
Status:INTERNET STANDARD
DOI:10.17487/RFC 0854
This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.
 
RFC 879 The TCP Maximum Segment Size and Related Topics
 
Authors:J. Postel.
Date:November 1983
Formats:txt pdf
Obsoleted by:RFC 7805
Updated by:RFC 6691
Status:HISTORIC
DOI:10.17487/RFC 0879
This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".
 
RFC 881 Domain names plan and schedule
 
Authors:J. Postel.
Date:November 1983
Formats:txt pdf
Updated by:RFC 0897
Status:UNKNOWN
DOI:10.17487/RFC 0881
This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.
 
RFC 882 Domain names: Concepts and facilities
 
Authors:P.V. Mockapetris.
Date:November 1983
Formats:txt pdf
Obsoleted by:RFC 1034, RFC 1035
Updated by:RFC 0973
Status:UNKNOWN
DOI:10.17487/RFC 0882
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
 
Authors:P.V. Mockapetris.
Date:November 1983
Formats:txt pdf
Obsoleted by:RFC 1034, RFC 1035
Updated by:RFC 0973
Status:UNKNOWN
DOI:10.17487/RFC 0883
This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.
 
RFC 888 "STUB" Exterior Gateway Protocol
 
Authors:L. Seamonson, E.C. Rosen.
Date:January 1984
Formats:txt pdf
Updated by:RFC 0904
Status:UNKNOWN
DOI:10.17487/RFC 0888
This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.
 
RFC 897 Domain name system implementation schedule
 
Authors:J. Postel.
Date:February 1984
Formats:txt pdf
Updates:RFC 0881
Updated by:RFC 0921
Status:UNKNOWN
DOI:10.17487/RFC 0897
This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.
 
RFC 907 Host Access Protocol specification
 
Authors:Bolt Beranek, Newman Laboratories.
Date:July 1984
Formats:txt pdf
Updated by:RFC 1221
Also:STD 0040
Status:INTERNET STANDARD
DOI:10.17487/RFC 0907
This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.
 
RFC 908 Reliable Data Protocol
 
Authors:D. Velten, R.M. Hinden, J. Sax.
Date:July 1984
Formats:txt pdf
Updated by:RFC 1151
Status:EXPERIMENTAL
DOI:10.17487/RFC 0908
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
 
RFC 950 Internet Standard Subnetting Procedure
 
Authors:J.C. Mogul, J. Postel.
Date:August 1985
Formats:txt pdf
Updates:RFC 0792
Updated by:RFC 6918
Also:STD 0005
Status:INTERNET STANDARD
DOI:10.17487/RFC 0950
This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.
 
RFC 951 Bootstrap Protocol
 
Authors:W.J. Croft, J. Gilmore.
Date:September 1985
Formats:txt pdf
Updated by:RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494
Status:DRAFT STANDARD
DOI:10.17487/RFC 0951
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
 
RFC 952 DoD Internet host table specification
 
Authors:K. Harrenstien, M.K. Stahl, E.J. Feinler.
Date:October 1985
Formats:txt pdf
Obsoletes:RFC 0810
Updated by:RFC 1123
Status:UNKNOWN
DOI:10.17487/RFC 0952
This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.
 
RFC 959 File Transfer Protocol
 
Authors:J. Postel, J. Reynolds.
Date:October 1985
Formats:txt pdf
Obsoletes:RFC 0765
Updated by:RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151
Also:STD 0009
Status:INTERNET STANDARD
DOI:10.17487/RFC 0959
This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.
 
RFC 976 UUCP mail interchange format standard
 
Authors:M.R. Horton.
Date:February 1986
Formats:txt pdf
Updated by:RFC 1137
Status:UNKNOWN
DOI:10.17487/RFC 0976
This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.
 
RFC 987 Mapping between X.400 and RFC 822
 
Authors:S.E. Kille.
Date:June 1986
Formats:txt pdf
Obsoleted by:RFC 2156, RFC 1327
Updated by:RFC 1026, RFC 1138, RFC 1148
Status:UNKNOWN
DOI:10.17487/RFC 0987
The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
 
RFC 990 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:November 1986
Formats:txt pdf
Obsoletes:RFC 0960
Obsoleted by:RFC 1010
Updated by:RFC 0997
Status:HISTORIC
DOI:10.17487/RFC 0990
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.
 
RFC 1006 ISO Transport Service on top of the TCP Version: 3
 
Authors:M.T. Rose, D.E. Cass.
Date:May 1987
Formats:txt pdf
Obsoletes:RFC 0983
Updated by:RFC 2126
Also:STD 0035
Status:INTERNET STANDARD
DOI:10.17487/RFC 1006
This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.
 
RFC 1011 Official Internet protocols
 
Authors:J.K. Reynolds, J. Postel.
Date:May 1987
Formats:txt pdf
Obsoletes:RFC 0991
Updated by:RFC 6093
Status:UNKNOWN
DOI:10.17487/RFC 1011
This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.
 
RFC 1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822)
 
Authors:S.E. Kille.
Date:September 1987
Formats:txt pdf
Obsoleted by:RFC 2156, RFC 1327
Updates:RFC 0987
Updated by:RFC 1138, RFC 1148
Status:UNKNOWN
DOI:10.17487/RFC 1026
This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.
 
RFC 1034 Domain names - concepts and facilities
 
Authors:P.V. Mockapetris.
Date:November 1987
Formats:txt pdf
Obsoletes:RFC 0973, RFC 0882, RFC 0883
Updated by:RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 4035, RFC 4592, RFC 5936, RFC 8020
Also:STD 0013
Status:INTERNET STANDARD
DOI:10.17487/RFC 1034
This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.
 
RFC 1035 Domain names - implementation and specification
 
Authors:P.V. Mockapetris.
Date:November 1987
Formats:txt pdf
Obsoletes:RFC 0973, RFC 0882, RFC 0883
Updated by:RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766
Also:STD 0013
Status:INTERNET STANDARD
DOI:10.17487/RFC 1035
This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
 
RFC 1041 Telnet 3270 regime option
 
Authors:Y. Rekhter.
Date:January 1988
Formats:txt pdf
Updated by:RFC 6270
Status:HISTORIC
DOI:10.17487/RFC 1041
This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.
 
RFC 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification
 
Authors:K. Hardwick, J. Lekashman.
Date:February 1988
Formats:txt pdf
Updated by:RFC 5494
Also:STD 0045
Status:INTERNET STANDARD
DOI:10.17487/RFC 1044
This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.
 
RFC 1058 Routing Information Protocol
 
Authors:C.L. Hedrick.
Date:June 1988
Formats:txt pdf
Updated by:RFC 1388, RFC 1723
Status:HISTORIC
DOI:10.17487/RFC 1058
This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.
 
RFC 1060 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:March 1990
Formats:txt pdf
Obsoletes:RFC 1010
Obsoleted by:RFC 1340
Updated by:RFC 1349
Status:HISTORIC
DOI:10.17487/RFC 1060
This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.
 
RFC 1071 Computing the Internet checksum
 
Authors:R.T. Braden, D.A. Borman, C. Partridge.
Date:September 1988
Formats:txt pdf
Updated by:RFC 1141
Status:INFORMATIONAL
DOI:10.17487/RFC 1071
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.
 
RFC 1112 Host extensions for IP multicasting
 
Authors:S.E. Deering.
Date:August 1989
Formats:txt pdf
Obsoletes:RFC 0988, RFC 1054
Updated by:RFC 2236
Also:STD 0005
Status:INTERNET STANDARD
DOI:10.17487/RFC 1112
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]
 
RFC 1122 Requirements for Internet Hosts - Communication Layers
 
Authors:R. Braden, Ed..
Date:October 1989
Formats:txt pdf
Updates:RFC 0793
Updated by:RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029
Also:STD 0003
Status:INTERNET STANDARD
DOI:10.17487/RFC 1122
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]
 
RFC 1123 Requirements for Internet Hosts - Application and Support
 
Authors:R. Braden, Ed..
Date:October 1989
Formats:txt pdf
Updates:RFC 0822, RFC 0952
Updated by:RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766
Also:STD 0003
Status:INTERNET STANDARD
DOI:10.17487/RFC 1123
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]
 
RFC 1138 Mapping between X.400(1988) / ISO 10021 and RFC 822
 
Authors:S.E. Kille.
Date:December 1989
Formats:txt pdf
Obsoleted by:RFC 2156, RFC 1327
Updates:RFC 1026, RFC 0987, RFC 0822
Updated by:RFC 1148
Status:EXPERIMENTAL
DOI:10.17487/RFC 1138
Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.
 
RFC 1141 Incremental updating of the Internet checksum
 
Authors:T. Mallory, A. Kullberg.
Date:January 1990
Formats:txt pdf
Updates:RFC 1071
Updated by:RFC 1624
Status:INFORMATIONAL
DOI:10.17487/RFC 1141
This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.
 
RFC 1149 Standard for the transmission of IP datagrams on avian carriers
 
Authors:D. Waitzman.
Date:1 April 1990
Formats:txt pdf
Updated by:RFC 2549, RFC 6214
Status:EXPERIMENTAL
DOI:10.17487/RFC 1149
This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.
 
RFC 1166 Internet numbers
 
Authors:S. Kirkpatrick, M.K. Stahl, M. Recker.
Date:July 1990
Formats:txt pdf
Obsoletes:RFC 1117, RFC 1062, RFC 1020
Updated by:RFC 5737
Status:INFORMATIONAL
DOI:10.17487/RFC 1166
This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.
 
RFC 1183 New DNS RR Definitions
 
Authors:C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris.
Date:October 1990
Formats:txt pdf
Updates:RFC 1034, RFC 1035
Updated by:RFC 5395, RFC 5864, RFC 6195, RFC 6895
Status:EXPERIMENTAL
DOI:10.17487/RFC 1183
This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.
 
RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments
 
Authors:R.W. Callon.
Date:December 1990
Formats:txt ps pdf
Updated by:RFC 1349, RFC 5302, RFC 5304
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1195
This RFC specifies an integrated routing protocol, based on the OSIIntra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering TaskForce.

The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of theOSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed inAnnex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available.

Comments should be sent to "isis@merit.edu".

 
RFC 1205 5250 Telnet interface
 
Authors:P. Chmielewski.
Date:February 1991
Formats:txt pdf
Updated by:RFC 2877
Status:INFORMATIONAL
DOI:10.17487/RFC 1205
This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II
 
Authors:K. McCloghrie, M. Rose.
Date:March 1991
Formats:txt pdf
Obsoletes:RFC 1158
Updated by:RFC 2011, RFC 2012, RFC 2013
Also:STD 0017
Status:INTERNET STANDARD
DOI:10.17487/RFC 1213
This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]
 
RFC 1229 Extensions to the generic-interface MIB
 
Authors:K. McCloghrie.
Date:May 1991
Formats:txt pdf
Obsoleted by:RFC 1573
Updated by:RFC 1239
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1229
This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK]
 
RFC 1230 IEEE 802.4 Token Bus MIB
 
Authors:K. McCloghrie, R. Fox.
Date:May 1991
Formats:txt pdf
Updated by:RFC 1239
Status:HISTORIC
DOI:10.17487/RFC 1230
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]
 
RFC 1231 IEEE 802.5 Token Ring MIB
 
Authors:K. McCloghrie, R. Fox, E. Decker.
Date:May 1991
Formats:txt pdf
Obsoleted by:RFC 1743, RFC 1748
Updated by:RFC 1239
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1231
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1232 Definitions of managed objects for the DS1 Interface type
 
Authors:F. Baker, C.P. Kolb.
Date:May 1991
Formats:txt pdf
Obsoleted by:RFC 1406
Updated by:RFC 1239
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1232
 
 
RFC 1233 Definitions of managed objects for the DS3 Interface type
 
Authors:T.A. Cox, K. Tesink.
Date:May 1991
Formats:txt pdf
Obsoleted by:RFC 1407
Updated by:RFC 1239
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1233
This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]
 
RFC 1242 Benchmarking Terminology for Network Interconnection Devices
 
Authors:S. Bradner.
Date:July 1991
Formats:txt pdf
Updated by:RFC 6201
Status:INFORMATIONAL
DOI:10.17487/RFC 1242
This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. The terms defined in this memo will be used in additional memos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).
 
RFC 1247 OSPF Version 2
 
Authors:J. Moy.
Date:July 1991
Formats:txt pdf ps
Obsoletes:RFC 1131
Obsoleted by:RFC 1583
Updated by:RFC 1349
Also:RFC 1245, RFC 1246
Status:DRAFT STANDARD
DOI:10.17487/RFC 1247
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]
 
RFC 1248 OSPF Version 2 Management Information Base
 
Authors:F. Baker, R. Coltun.
Date:July 1991
Formats:txt pdf
Obsoleted by:RFC 1252
Updated by:RFC 1349
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1248
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
 
RFC 1271 Remote Network Monitoring Management Information Base
 
Authors:S. Waldbusser.
Date:November 1991
Formats:txt pdf
Obsoleted by:RFC 1757
Updated by:RFC 1513
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1271
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]
 
RFC 1285 FDDI Management Information Base
 
Authors:J. Case.
Date:January 1992
Formats:txt pdf
Updated by:RFC 1512
Status:HISTORIC
DOI:10.17487/RFC 1285
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]
 
RFC 1321 The MD5 Message-Digest Algorithm
 
Authors:R. Rivest.
Date:April 1992
Formats:txt pdf
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 1321
This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822
 
Authors:S. Hardcastle-Kille.
Date:May 1992
Formats:txt pdf
Obsoletes:RFC 0987, RFC 1026, RFC 1138, RFC 1148
Obsoleted by:RFC 2156
Updates:RFC 0822
Updated by:RFC 1495
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1327
This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988)Recommendations on Message Handling Systems / ISO IEC 10021 MessageOriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings.The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148[Kille86a,Kille87a] which it obsoletes.

This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on theDARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected.

 
RFC 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks
 
Authors:P. Kuehn.
Date:May 1992
Formats:txt pdf
Updated by:RFC 5494
Status:INFORMATIONAL
DOI:10.17487/RFC 1329
In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP)
 
Authors:G. McGregor.
Date:May 1992
Formats:txt pdf
Obsoletes:RFC 1172
Updated by:RFC 3241
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1332
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the NCP for establishing and configuring theInternet Protocol [2] over PPP, and a method to negotiate and use VanJacobson TCP/IP header compression [3] with PPP.

This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).

 
RFC 1350 The TFTP Protocol (Revision 2)
 
Authors:K. Sollins.
Date:July 1992
Formats:txt pdf
Obsoletes:RFC 0783
Updated by:RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349
Also:STD 0033
Status:INTERNET STANDARD
DOI:10.17487/RFC 1350
TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]
 
RFC 1379 Extending TCP for Transactions -- Concepts
 
Authors:R. Braden.
Date:November 1992
Formats:txt pdf
Obsoleted by:RFC 6247
Updated by:RFC 1644
Status:HISTORIC
DOI:10.17487/RFC 1379
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.

This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.

 
RFC 1408 Telnet Environment Option
 
Authors:D. Borman, Ed..
Date:January 1993
Formats:txt pdf
Updated by:RFC 1571
Status:HISTORIC
DOI:10.17487/RFC 1408
This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.
 
RFC 1459 Internet Relay Chat Protocol
 
Authors:J. Oikarinen, D. Reed.
Date:May 1993
Formats:txt pdf
Updated by:RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194
Status:EXPERIMENTAL
DOI:10.17487/RFC 1459
The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.

 
RFC 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
 
Authors:N. Borenstein, N. Freed.
Date:September 1993
Formats:txt pdf ps
Obsoletes:RFC 1341
Obsoleted by:RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Updated by:RFC 1590
Status:DRAFT STANDARD
DOI:10.17487/RFC 1521
STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC822.

In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.

This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data. Such extensions are the subject of a companion document [RFC-1522].

This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H.

 
RFC 1548 The Point-to-Point Protocol (PPP)
 
Authors:W. Simpson.
Date:December 1993
Formats:txt pdf
Obsoletes:RFC 1331
Obsoleted by:RFC 1661
Updated by:RFC 1570
Status:DRAFT STANDARD
DOI:10.17487/RFC 1548
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:

1. A method for encapsulating multi-protocol datagrams.

2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.

3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.

This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1570 PPP LCP Extensions
 
Authors:W. Simpson, Ed..
Date:January 1994
Formats:txt pdf
Updates:RFC 1548
Updated by:RFC 2484
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1570
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years.

This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1602 The Internet Standards Process -- Revision 2
 
Authors:Internet Architecture Board, Internet Engineering Steering Group.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1310
Obsoleted by:RFC 2026
Updated by:RFC 1871
Status:INFORMATIONAL
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
 
Authors:E. Huizer, D. Crocker.
Date:March 1994
Formats:txt pdf
Obsoleted by:RFC 2418
Updated by:RFC 1871
Status:INFORMATIONAL
DOI:10.17487/RFC 1603
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined.
 
RFC 1661 The Point-to-Point Protocol (PPP)
 
Authors:W. Simpson, Ed..
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1548
Updated by:RFC 2153
Also:STD 0051
Status:INTERNET STANDARD
DOI:10.17487/RFC 1661
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:

1. A method for encapsulating multi-protocol datagrams.

2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.

3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.

 
RFC 1715 The H Ratio for Address Assignment Efficiency
 
Authors:C. Huitema.
Date:November 1994
Formats:txt pdf
Updated by:RFC 3194
Status:INFORMATIONAL
DOI:10.17487/RFC 1715
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list.
 
RFC 1738 Uniform Resource Locators (URL)
 
Authors:T. Berners-Lee, L. Masinter, M. McCahill.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 4248, RFC 4266
Updated by:RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270, RFC 8089
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1738
This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.
 
RFC 1748 IEEE 802.5 MIB using SMIv2
 
Authors:K. McCloghrie, E. Decker.
Date:December 1994
Formats:txt pdf
Obsoletes:RFC 1743, RFC 1231
Updated by:RFC 1749
Status:DRAFT STANDARD
DOI:10.17487/RFC 1748
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1778 The String Representation of Standard Attribute Syntaxes
 
Authors:T. Howes, S. Kille, W. Yeong, C. Robbins.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1488
Obsoleted by:RFC 3494
Updated by:RFC 2559
Status:HISTORIC
DOI:10.17487/RFC 1778
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
 
RFC 1793 Extending OSPF to Support Demand Circuits
 
Authors:J. Moy.
Date:April 1995
Formats:txt pdf
Updated by:RFC 3883
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1793
This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.

Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.

While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.

The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface).

This memo provides functionality similar to that specified for RIP in[2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, becauseOSPF employs link-state routing technology as opposed to RIP'sDistance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.

Please send comments to ospf@gated.cornell.edu.

 
RFC 1808 Relative Uniform Resource Locators
 
Authors:R. Fielding.
Date:June 1995
Formats:txt pdf
Obsoleted by:RFC 3986
Updates:RFC 1738
Updated by:RFC 2368, RFC 2396
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1808
A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators.
 
RFC 1812 Requirements for IP Version 4 Routers
 
Authors:F. Baker, Ed..
Date:June 1995
Formats:txt pdf
Obsoletes:RFC 1716, RFC 1009
Updated by:RFC 2644, RFC 6633
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1812
This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]
 
RFC 1833 Binding Protocols for ONC RPC Version 2
 
Authors:R. Srinivasan.
Date:August 1995
Formats:txt pdf
Updated by:RFC 5665
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1833
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]
 
RFC 1846 SMTP 521 Reply Code
 
Authors:A. Durand, F. Dupont.
Date:September 1995
Formats:txt pdf
Updated by:RFC 7504
Status:EXPERIMENTAL
DOI:10.17487/RFC 1846
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.
 
RFC 1858 Security Considerations for IP Fragment Filtering
 
Authors:G. Ziemba, D. Reed, P. Traina.
Date:October 1995
Formats:txt pdf
Updated by:RFC 3128
Status:INFORMATIONAL
DOI:10.17487/RFC 1858
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them.
 
RFC 1886 DNS Extensions to support IP version 6
 
Authors:S. Thomson, C. Huitema.
Date:December 1995
Formats:txt pdf
Obsoleted by:RFC 3596
Updated by:RFC 2874, RFC 3152
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1886
This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.
 
RFC 1888 OSI NSAPs and IPv6
 
Authors:J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd.
Date:August 1996
Formats:txt pdf
Obsoleted by:RFC 4048
Updated by:RFC 4548
Status:HISTORIC
DOI:10.17487/RFC 1888
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.
 
RFC 1894 An Extensible Message Format for Delivery Status Notifications
 
Authors:K. Moore, G. Vaudreuil.
Date:January 1996
Formats:txt pdf
Obsoleted by:RFC 3464
Updated by:RFC 2852
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1894
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.

Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.

NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.

 
RFC 1918 Address Allocation for Private Internets
 
Authors:Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear.
Date:February 1996
Formats:txt pdf
Obsoletes:RFC 1627, RFC 1597
Updated by:RFC 6761
Also:BCP 0005
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1918
This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS)
 
Authors:J. Hawkinson, T. Bates.
Date:March 1996
Formats:txt pdf
Updated by:RFC 6996, RFC 7300
Also:BCP 0006
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1930
This memo discusses when it is appropriate to register and utilize anAutonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior GatewayProtocol, now at historical status; see [EGP]), BGP (Border GatewayProtocol, the current de facto standard for inter-AS routing; see[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which theInternet is expected to adopt when BGP becomes obsolete; see [IDRP]).It should be noted that the IDRP equivalent of an AS is the RDI, orRouting Domain Identifier.
 
RFC 1939 Post Office Protocol - Version 3
 
Authors:J. Myers, M. Rose.
Date:May 1996
Formats:txt pdf
Obsoletes:RFC 1725
Updated by:RFC 1957, RFC 2449, RFC 6186, RFC 8314
Also:STD 0053
Status:INTERNET STANDARD
DOI:10.17487/RFC 1939
The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]
 
RFC 1958 Architectural Principles of the Internet
 
Authors:B. Carpenter, Ed..
Date:June 1996
Formats:txt pdf
Updated by:RFC 3439
Status:INFORMATIONAL
DOI:10.17487/RFC 1958
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.
 
RFC 1962 The PPP Compression Control Protocol (CCP)
 
Authors:D. Rand.
Date:June 1996
Formats:txt pdf
Updated by:RFC 2153
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1962
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.

This document defines a method for negotiating data compression overPPP links.

 
RFC 1964 The Kerberos Version 5 GSS-API Mechanism
 
Authors:J. Linn.
Date:June 1996
Formats:txt pdf
Updated by:RFC 4121, RFC 6649
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1964
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK]
 
RFC 1966 BGP Route Reflection An alternative to full mesh IBGP
 
Authors:T. Bates, R. Chandra.
Date:June 1996
Formats:txt pdf
Obsoleted by:RFC 4456
Updated by:RFC 2796
Status:EXPERIMENTAL
DOI:10.17487/RFC 1966
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].

This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP.

 
RFC 1987 Ipsilon's General Switch Management Protocol Specification Version 1.1
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:August 1996
Formats:txt pdf
Updated by:RFC 2297
Status:INFORMATIONAL
DOI:10.17487/RFC 1987
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.
 
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
 
Authors:W. Simpson.
Date:August 1996
Formats:txt pdf
Obsoletes:RFC 1334
Updated by:RFC 2484
Status:DRAFT STANDARD
DOI:10.17487/RFC 1994
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key.

 
RFC 1997 BGP Communities Attribute
 
Authors:R. Chandra, P. Traina, T. Li.
Date:August 1996
Formats:txt pdf
Updated by:RFC 7606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1997
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets.

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers.

The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.

 
RFC 2002 IP Mobility Support
 
Authors:C. Perkins, Ed..
Date:October 1996
Formats:txt pdf
Obsoleted by:RFC 3220
Updated by:RFC 2290
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2002
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
 
RFC 2003 IP Encapsulation within IP
 
Authors:C. Perkins.
Date:October 1996
Formats:txt pdf
Updated by:RFC 3168, RFC 6864
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2003
This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IPDestination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP.
 
RFC 2015 MIME Security with Pretty Good Privacy (PGP)
 
Authors:M. Elkins.
Date:October 1996
Formats:txt pdf
Updated by:RFC 3156
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2015
This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC1847.
 
RFC 2026 The Internet Standards Process -- Revision 3
 
Authors:S. Bradner.
Date:October 1996
Formats:txt pdf
Obsoletes:RFC 1602, RFC 1871
Updated by:RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179
Also:BCP 0009
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2026
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
 
RFC 2028 The Organizations Involved in the IETF Standards Process
 
Authors:R. Hovey, S. Bradner.
Date:October 1996
Formats:txt pdf
Updated by:RFC 3668, RFC 3979
Also:BCP 0011
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2028
This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF WorkingGroups and the relationship between the IETF and the InternetSociety.
 
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
 
Authors:N. Freed, N. Borenstein.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2184, RFC 2231, RFC 5335, RFC 6532
Status:DRAFT STANDARD
DOI:10.17487/RFC 2045
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in

Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions.

 
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
 
Authors:N. Freed, N. Borenstein.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098
Status:DRAFT STANDARD
DOI:10.17487/RFC 2046
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document,RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

 
RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
 
Authors:K. Moore.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2184, RFC 2231
Status:DRAFT STANDARD
DOI:10.17487/RFC 2047
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other than US-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other than US-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data inInternet mail header fields.

Other documents in this series include:

+ RFC 2045, which specifies the various headers used to describe the structure of MIME messages.

+ RFC 2046, which defines the general structure of the MIME media typing system and defines an initial set of media types,

+ RFC 2048, which specifies various IANA registration procedures for MIME-related facilities, and

+ RFC 2049, which describes MIME conformance criteria and provides some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions.

 
RFC 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
 
Authors:N. Freed, J. Klensin, J. Postel.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Obsoleted by:RFC 4288, RFC 4289
Updated by:RFC 3023
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2048
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities:

(1) media types,

(2) external body access types,

(3) content-transfer-encodings.

Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document.

These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

 
RFC 2072 Router Renumbering Guide
 
Authors:H. Berkowitz.
Date:January 1997
Formats:txt pdf
Updated by:RFC 4192
Status:INFORMATIONAL
DOI:10.17487/RFC 2072
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes inInternet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.

Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.

 
RFC 2088 IMAP4 non-synchronizing literals
 
Authors:J. Myers.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 7888
Updated by:RFC 4466
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2088
The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK]
 
RFC 2104 HMAC: Keyed-Hashing for Message Authentication
 
Authors:H. Krawczyk, M. Bellare, R. Canetti.
Date:February 1997
Formats:txt pdf
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 2104
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function.
 
RFC 2113 IP Router Alert Option
 
Authors:D. Katz.
Date:February 1997
Formats:txt pdf
Updated by:RFC 5350, RFC 6398
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2113
This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.
 
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels
 
Authors:S. Bradner.
Date:March 1997
Formats:txt pdf
Updated by:RFC 8174
Also:BCP 0014
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2119
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
 
RFC 2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996
 
Authors:C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg.
Date:April 1997
Formats:txt pdf
Updated by:RFC 6055
Status:INFORMATIONAL
DOI:10.17487/RFC 2130
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols.
 
RFC 2131 Dynamic Host Configuration Protocol
 
Authors:R. Droms.
Date:March 1997
Formats:txt pdf
Obsoletes:RFC 1541
Updated by:RFC 3396, RFC 4361, RFC 5494, RFC 6842
Status:DRAFT STANDARD
DOI:10.17487/RFC 2131
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9].
 
RFC 2132 DHCP Options and BOOTP Vendor Extensions
 
Authors:S. Alexander, R. Droms.
Date:March 1997
Formats:txt pdf
Obsoletes:RFC 1533
Updated by:RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494
Status:DRAFT STANDARD
DOI:10.17487/RFC 2132
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called"options."

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments [22].

All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions.

 
RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
 
Authors:P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound.
Date:April 1997
Formats:txt pdf
Updates:RFC 1035
Updated by:RFC 3007, RFC 4035, RFC 4033, RFC 4034
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2136
The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR.

UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met.

 
RFC 2153 PPP Vendor Extensions
 
Authors:W. Simpson.
Date:May 1997
Formats:txt pdf
Updates:RFC 1661, RFC 1962
Updated by:RFC 5342, RFC 7042
Status:INFORMATIONAL
DOI:10.17487/RFC 2153
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines a general mechanism for proprietary vendor extensions.

 
RFC 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)
 
Authors:C. Allocchio.
Date:January 1998
Formats:txt pdf
Obsoletes:RFC 1664
Updated by:RFC 3597
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2163
This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed.

This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.

RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group.

 
RFC 2165 Service Location Protocol
 
Authors:J. Veizades, E. Guttman, C. Perkins, S. Kaplan.
Date:June 1997
Formats:txt pdf
Updated by:RFC 2608, RFC 2609
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2165
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
 
RFC 2168 Resolution of Uniform Resource Identifiers using the Domain Name System
 
Authors:R. Daniel, M. Mealling.
Date:June 1997
Formats:txt pdf
Obsoleted by:RFC 3401, RFC 3402, RFC 3403, RFC 3404
Updated by:RFC 2915
Status:EXPERIMENTAL
DOI:10.17487/RFC 2168
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2176 IPv4 over MAPOS Version 1
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Updated by:RFC 5494
Status:INFORMATIONAL
DOI:10.17487/RFC 2176
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP).
 
RFC 2181 Clarifications to the DNS Specification
 
Authors:R. Elz, R. Bush.
Date:July 1997
Formats:txt pdf
Updates:RFC 1034, RFC 1035, RFC 1123
Updated by:RFC 4035, RFC 2535, RFC 4343, RFC 4033, RFC 4034, RFC 5452
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2181
This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK]
 
RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
 
Authors:R. Troost, S. Dorner, K. Moore, Ed..
Date:August 1997
Formats:txt pdf
Obsoletes:RFC 1806
Updated by:RFC 2184, RFC 2231
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2183
This memo provides a mechanism whereby messages conforming to theMIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC2049] can convey presentational information. It specifies the"Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.

This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and[RFC 822]. The information presented herein supplements but does not replace that found in those documents.

This document is a revision to the Experimental protocol defined inRFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the FileTransfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values.

 
RFC 2198 RTP Payload for Redundant Audio Data
 
Authors:C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis.
Date:September 1997
Formats:txt pdf
Updated by:RFC 6354
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2198
This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications.
 
RFC 2203 RPCSEC_GSS Protocol Specification
 
Authors:M. Eisler, A. Chiu, L. Ling.
Date:September 1997
Formats:txt pdf
Updated by:RFC 5403
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2203
This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services ApplicationProgramming Interface (referred to henceforth as GSS-API).
 
RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
 
Authors:R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin.
Date:September 1997
Formats:txt pdf
Updated by:RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2205
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
 
RFC 2222 Simple Authentication and Security Layer (SASL)
 
Authors:J. Myers.
Date:October 1997
Formats:txt pdf
Obsoleted by:RFC 4422, RFC 4752
Updated by:RFC 2444
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2222
This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]
 
RFC 2223 Instructions to RFC Authors
 
Authors:J. Postel, J. Reynolds.
Date:October 1997
Formats:txt pdf
Obsoletes:RFC 1543, RFC 1111, RFC 0825
Obsoleted by:RFC 7322
Updated by:RFC 5741, RFC 6949
Status:INFORMATIONAL
DOI:10.17487/RFC 2223
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2225 Classical IP and ARP over ATM
 
Authors:M. Laubach, J. Halpern.
Date:April 1998
Formats:txt pdf
Obsoletes:RFC 1626, RFC 1577
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2225
This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]
 
RFC 2236 Internet Group Management Protocol, Version 2
 
Authors:W. Fenner.
Date:November 1997
Formats:txt pdf
Updates:RFC 1112
Updated by:RFC 3376
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2236
This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112.

IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.

This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s).

 
RFC 2244 ACAP -- Application Configuration Access Protocol
 
Authors:C. Newman, J. G. Myers.
Date:November 1997
Formats:txt pdf
Updated by:RFC 6075
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2244
The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.
 
RFC 2246 The TLS Protocol Version 1.0
 
Authors:T. Dierks, C. Allen.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 4346
Updated by:RFC 3546, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2246
This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
 
RFC 2247 Using Domains in LDAP/X.500 Distinguished Names
 
Authors:S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri.
Date:January 1998
Formats:txt pdf
Updated by:RFC 4519, RFC 4524
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2247
This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]
 
RFC 2251 Lightweight Directory Access Protocol (v3)
 
Authors:M. Wahl, T. Howes, S. Kille.
Date:December 1997
Formats:txt pdf
Obsoleted by:RFC 4510, RFC 4511, RFC 4513, RFC 4512
Updated by:RFC 3377, RFC 3771
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2251
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
 
Authors:M. Wahl, A. Coulbeck, T. Howes, S. Kille.
Date:December 1997
Formats:txt pdf
Obsoleted by:RFC 4510, RFC 4517, RFC 4523, RFC 4512
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2252
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
 
Authors:M. Wahl, S. Kille, T. Howes.
Date:December 1997
Formats:txt pdf
Obsoletes:RFC 1779
Obsoleted by:RFC 4510, RFC 4514
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2253
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
 
Authors:T. Howes.
Date:December 1997
Formats:txt pdf
Obsoletes:RFC 1960
Obsoleted by:RFC 4510, RFC 4515
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2254
This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
 
RFC 2255 The LDAP URL Format
 
Authors:T. Howes, M. Smith.
Date:December 1997
Formats:txt pdf
Obsoletes:RFC 1959
Obsoleted by:RFC 4510, RFC 4516
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2255
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
 
Authors:M. Wahl.
Date:December 1997
Formats:txt pdf
Obsoleted by:RFC 4517, RFC 4519, RFC 4523, RFC 4512, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2256
This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK]
 
RFC 2276 Architectural Principles of Uniform Resource Name Resolution
 
Authors:K. Sollins.
Date:January 1998
Formats:txt pdf
Updated by:RFC 3401
Status:INFORMATIONAL
DOI:10.17487/RFC 2276
This document addresses the issues of the discovery of URN (UniformResource Name) resolver services that in turn will directly translateURNs into URLs (Uniform Resource Locators) and URCs (Uniform ResourceCharacteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately.
 
RFC 2284 PPP Extensible Authentication Protocol (EAP)
 
Authors:L. Blunk, J. Vollbrecht.
Date:March 1998
Formats:txt pdf
Obsoleted by:RFC 3748
Updated by:RFC 2484
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2284
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.

This document defines the PPP Extensible Authentication Protocol.

 
RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP
 
Authors:J. Solomon, S. Glass.
Date:February 1998
Formats:txt pdf
Updates:RFC 2002
Updated by:RFC 2794
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2290
Mobile IP [RFC 2002] defines media-independent procedures by which aMobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to theInternet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP[RFC 1332], and PPP [RFC 1661] is assumed.
 
RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
 
Authors:M. Andrews.
Date:March 1998
Formats:txt pdf
Updates:RFC 1034, RFC 1035
Updated by:RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2308
[RFC1034] provided a description of how to cache negative responses.It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section4.3.4].

Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name.

Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver.

 
RFC 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet
 
Authors:B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang.
Date:April 1998
Formats:txt pdf
Obsoleted by:RFC 7567
Updated by:RFC 7141
Status:INFORMATIONAL
DOI:10.17487/RFC 2309
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
 
RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
 
Authors:L. Masinter.
Date:1 April 1998
Formats:txt pdf
Updated by:RFC 7168
Status:INFORMATIONAL
DOI:10.17487/RFC 2324
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.
 
RFC 2327 SDP: Session Description Protocol
 
Authors:M. Handley, V. Jacobson.
Date:April 1998
Formats:txt pdf
Obsoleted by:RFC 4566
Updated by:RFC 3266
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2327
This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors.

 
RFC 2328 OSPF Version 2
 
Authors:J. Moy.
Date:April 1998
Formats:txt pdf
Obsoletes:RFC 2178
Updated by:RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042
Also:STD 0054
Status:INTERNET STANDARD
DOI:10.17487/RFC 2328
This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.

The differences between this memo and RFC 2178 are explained inAppendix G. All differences are backward-compatible in nature.

Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.

Please send comments to ospf@gated.cornell.edu.

 
RFC 2330 Framework for IP Performance Metrics
 
Authors:V. Paxson, G. Almes, J. Mahdavi, M. Mathis.
Date:May 1998
Formats:txt pdf
Updated by:RFC 7312, RFC 8468
Status:INFORMATIONAL
DOI:10.17487/RFC 2330
The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2342 IMAP4 Namespace
 
Authors:M. Gahrns, C. Newman.
Date:May 1998
Formats:txt pdf
Updated by:RFC 4466
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2342
This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS- TRACK]
 
RFC 2355 TN3270 Enhancements
 
Authors:B. Kelly.
Date:June 1998
Formats:txt pdf
Obsoletes:RFC 1647
Updated by:RFC 6270
Status:DRAFT STANDARD
DOI:10.17487/RFC 2355
This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.

This protocol is negotiated under the TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime Option as defined in RFC 1041[1].

 
RFC 2370 The OSPF Opaque LSA Option
 
Authors:R. Coltun.
Date:July 1998
Formats:txt pdf
Obsoleted by:RFC 5250
Updated by:RFC 3630
Also:RFC 2328
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2370
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]
 
RFC 2377 Naming Plan for Internet Directory-Enabled Applications
 
Authors:A. Grimstad, R. Huber, S. Sataluri, M. Wahl.
Date:September 1998
Formats:txt pdf
Updated by:RFC 4519
Status:INFORMATIONAL
DOI:10.17487/RFC 2377
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach.
 
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
 
Authors:A. Heffernan.
Date:August 1998
Formats:txt pdf
Obsoleted by:RFC 5925
Updated by:RFC 6691
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2385
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP.
 
RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
 
Authors:T. Berners-Lee, R. Fielding, L. Masinter.
Date:August 1998
Formats:txt pdf
Obsoleted by:RFC 3986
Updates:RFC 1808, RFC 1738
Updated by:RFC 2732
Status:DRAFT STANDARD
DOI:10.17487/RFC 2396
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme.

 
RFC 2401 Security Architecture for the Internet Protocol
 
Authors:S. Kent, R. Atkinson.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 1825
Obsoleted by:RFC 4301
Updated by:RFC 3168
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2401
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]
 
RFC 2409 The Internet Key Exchange (IKE)
 
Authors:D. Harkins, D. Carrel.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 4306
Updated by:RFC 4109
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2409
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]
 
RFC 2418 IETF Working Group Guidelines and Procedures
 
Authors:S. Bradner.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1603
Updated by:RFC 3934, RFC 7475, RFC 7776
Also:BCP 0025
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2418
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF AreaDirectors.
 
RFC 2434 Guidelines for Writing an IANA Considerations Section in RFCs
 
Authors:T. Narten, H. Alvestrand.
Date:October 1998
Formats:txt pdf
Obsoleted by:RFC 5226
Updated by:RFC 3692
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2434
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).

In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.

 
RFC 2449 POP3 Extension Mechanism
 
Authors:R. Gellens, C. Newman, L. Lundblade.
Date:November 1998
Formats:txt pdf
Updates:RFC 1939
Updated by:RFC 5034
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2449
This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]
 
RFC 2453 RIP Version 2
 
Authors:G. Malkin.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 1723
Updated by:RFC 4822
Also:STD 0056
Status:INTERNET STANDARD
DOI:10.17487/RFC 2453
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.

A companion document will define the SNMP MIB objects for RIP-2 [2].An additional document will define cryptographic security improvements for RIP-2 [3].

 
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
 
Authors:S. Deering, R. Hinden.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1883
Obsoleted by:RFC 8200
Updated by:RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112
Status:DRAFT STANDARD
DOI:10.17487/RFC 2460
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.
 
RFC 2461 Neighbor Discovery for IP Version 6 (IPv6)
 
Authors:T. Narten, E. Nordmark, W. Simpson.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1970
Obsoleted by:RFC 4861
Updated by:RFC 4311
Status:DRAFT STANDARD
DOI:10.17487/RFC 2461
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
 
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
 
Authors:M. Crawford.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1972
Updated by:RFC 6085, RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2464
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]
 
RFC 2467 Transmission of IPv6 Packets over FDDI Networks
 
Authors:M. Crawford.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 2019
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2467
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS- TRACK]
 
RFC 2470 Transmission of IPv6 Packets over Token Ring Networks
 
Authors:M. Crawford, T. Narten, S. Thomas.
Date:December 1998
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2470
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]
 
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
 
Authors:K. Nichols, S. Blake, F. Baker, D. Black.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1455, RFC 1349
Updates:RFC 0791
Updated by:RFC 3168, RFC 3260, RFC 8436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2474
Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:

- setting bits in an IP header field at network boundaries(autonomous system boundaries, internal administrative boundaries, or hosts),- using those bits to determine how packets are forwarded by the nodes inside the network, and- conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.

The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.

This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.

For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].

 
RFC 2475 An Architecture for Differentiated Services
 
Authors:S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.
Date:December 1998
Formats:txt pdf
Updated by:RFC 3260
Status:INFORMATIONAL
DOI:10.17487/RFC 2475
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field[DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.
 
RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks
 
Authors:G. Armitage, P. Schulter, M. Jork, G. Harter.
Date:January 1999
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2491
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.

Dynamic NBMA shortcuts are achieved through the use of IPv6 NeighborDiscovery protocol operation within Logical Links, and inter-routerNHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported.

 
RFC 2492 IPv6 over ATM Networks
 
Authors:G. Armitage, P. Schulter, M. Jork.
Date:January 1999
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2492
This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths(when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.
 
RFC 2497 Transmission of IPv6 Packets over ARCnet Networks
 
Authors:I. Souvatzis.
Date:January 1999
Formats:txt pdf
Updated by:RFC 8064
Also:RFC 1201
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2497
This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]
 
RFC 2533 A Syntax for Describing Media Feature Sets
 
Authors:G. Klyne.
Date:March 1999
Formats:txt pdf
Updated by:RFC 2738, RFC 2938
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2533
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1].A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3].

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.

An algorithm for feature set matching is also described here.

 
RFC 2535 Domain Name System Security Extensions
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 2065
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 2181, RFC 1035, RFC 1034
Updated by:RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2535
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.

The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.

In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.

This document incorporates feedback on RFC 2065 from early implementers and potential users.

 
RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2536
A standard method for storing US Government Digital SignatureAlgorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.
 
RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2539
A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records.
 
RFC 2544 Benchmarking Methodology for Network Interconnect Devices
 
Authors:S. Bradner, J. McQuaid.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 1944
Updated by:RFC 6201, RFC 6815
Status:INFORMATIONAL
DOI:10.17487/RFC 2544
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing.
 
RFC 2553 Basic Socket Interface Extensions for IPv6
 
Authors:R. Gilligan, S. Thomson, J. Bound, W. Stevens.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 2133
Obsoleted by:RFC 3493
Updated by:RFC 3152
Status:INFORMATIONAL
DOI:10.17487/RFC 2553
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4].
 
RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
 
Authors:M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
Date:June 1999
Formats:txt pdf
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 2581 TCP Congestion Control
 
Authors:M. Allman, V. Paxson, W. Stevens.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2001
Obsoleted by:RFC 5681
Updated by:RFC 3390
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2581
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.
 
RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification
 
Authors:A. Conta, A. Malis, M. Mueller.
Date:May 1999
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2590
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
 
RFC 2595 Using TLS with IMAP, POP3 and ACAP
 
Authors:C. Newman.
Date:June 1999
Formats:txt pdf
Updated by:RFC 4616, RFC 7817, RFC 8314
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2595
Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]
 
RFC 2597 Assured Forwarding PHB Group
 
Authors:J. Heinanen, F. Baker, W. Weiss, J. Wroclawski.
Date:June 1999
Formats:txt pdf
Updated by:RFC 3260
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2597
This document defines a general use Differentiated Services (DS)[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.
 
RFC 2606 Reserved Top Level DNS Names
 
Authors:D. Eastlake 3rd, A. Panitz.
Date:June 1999
Formats:txt pdf
Updated by:RFC 6761
Also:BCP 0032
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2606
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented.
 
RFC 2608 Service Location Protocol, Version 2
 
Authors:E. Guttman, C. Perkins, J. Veizades, M. Day.
Date:June 1999
Formats:txt pdf
Updates:RFC 2165
Updated by:RFC 3224
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2608
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
 
RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
 
Authors:R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
Date:June 1999
Formats:txt ps pdf
Obsoletes:RFC 2068
Obsoleted by:RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Updated by:RFC 2817, RFC 5785, RFC 6266, RFC 6585
Status:DRAFT STANDARD
DOI:10.17487/RFC 2616
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].

 
RFC 2622 Routing Policy Specification Language (RPSL)
 
Authors:C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 2280
Updated by:RFC 4012, RFC 7909
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2622
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
 
RFC 2634 Enhanced Security Services for S/MIME
 
Authors:P. Hoffman, Ed..
Date:June 1999
Formats:txt pdf
Updated by:RFC 5035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2634
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]
 
RFC 2648 A URN Namespace for IETF Documents
 
Authors:R. Moats.
Date:August 1999
Formats:txt pdf
Updated by:RFC 6924
Status:INFORMATIONAL
DOI:10.17487/RFC 2648
A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace.
 
RFC 2672 Non-Terminal DNS Name Redirection
 
Authors:M. Crawford.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 6672
Updated by:RFC 4592, RFC 6604
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2672
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
 
Authors:M. Crawford.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 6891
Updates:RFC 1035
Updated by:RFC 3363, RFC 3364
Status:HISTORIC
DOI:10.17487/RFC 2673
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]
 
RFC 2683 IMAP4 Implementation Recommendations
 
Authors:B. Leiba.
Date:September 1999
Formats:txt pdf
Updated by:RFC 7162
Status:INFORMATIONAL
DOI:10.17487/RFC 2683
The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.
 
RFC 2705 Media Gateway Control Protocol (MGCP) Version 1.0
 
Authors:M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett.
Date:October 1999
Formats:txt pdf
Obsoleted by:RFC 3435
Updated by:RFC 3660
Status:INFORMATIONAL
DOI:10.17487/RFC 2705
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.

The document is structured in 6 main sections:

* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.

* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.

* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.

* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).

* The event packages section provides an initial definition of packages and event names.

* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0.

 
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
 
Authors:S. Deering, W. Fenner, B. Haberman.
Date:October 1999
Formats:txt pdf
Updated by:RFC 3590, RFC 3810
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2710
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as MulticastListener Discovery or MLD. MLD is derived from version 2 of IPv4'sInternet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
 
RFC 2711 IPv6 Router Alert Option
 
Authors:C. Partridge, A. Jackson.
Date:October 1999
Formats:txt pdf
Updated by:RFC 6398
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2711
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
 
RFC 2725 Routing Policy System Security
 
Authors:C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy.
Date:December 1999
Formats:txt pdf
Updated by:RFC 4012
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2725
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
 
RFC 2736 Guidelines for Writers of RTP Payload Format Specifications
 
Authors:M. Handley, C. Perkins.
Date:December 1999
Formats:txt pdf
Updated by:RFC 8088
Also:BCP 0036
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2736
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.
 
RFC 2739 Calendar Attributes for vCard and LDAP
 
Authors:T. Small, D. Hennessy, F. Dawson.
Date:January 2000
Formats:txt pdf
Updated by:RFC 6350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2739
When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event.

In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time.

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include:

- Manual transfer of the information;

- Personal data exchange using the vCard format; and

- Directory lookup using the LDAP protocol.

 
RFC 2743 Generic Security Service Application Program Interface Version 2, Update 1
 
Authors:J. Linn.
Date:January 2000
Formats:txt pdf
Obsoletes:RFC 2078
Updated by:RFC 5554
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2743
The Generic Security Service Application Program Interface (GSS-API),Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms

This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.

 
RFC 2747 RSVP Cryptographic Authentication
 
Authors:F. Baker, B. Lindell, M. Talwar.
Date:January 2000
Formats:txt pdf
Updated by:RFC 3097
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2747
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
 
RFC 2748 The COPS (Common Open Policy Service) Protocol
 
Authors:D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry.
Date:January 2000
Formats:txt pdf
Updated by:RFC 4261
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2748
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
 
RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
 
Authors:G. Tsirtsis, P. Srisuresh.
Date:February 2000
Formats:txt pdf
Obsoleted by:RFC 4966
Updated by:RFC 3152
Status:HISTORIC
DOI:10.17487/RFC 2766
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT].
 
RFC 2772 6Bone Backbone Routing Guidelines
 
Authors:R. Rockell, R. Fink.
Date:February 2000
Formats:txt pdf
Obsoletes:RFC 2546
Updated by:RFC 3152
Status:INFORMATIONAL
DOI:10.17487/RFC 2772
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.

This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.

 
RFC 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers
 
Authors:S. Bradner, V. Paxson.
Date:March 2000
Formats:txt pdf
Updated by:RFC 4443, RFC 5237, RFC 5771, RFC 6335, RFC 7045
Also:BCP 0037
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2780
This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers.
 
RFC 2782 A DNS RR for specifying the location of services (DNS SRV)
 
Authors:A. Gulbrandsen, P. Vixie, L. Esibov.
Date:February 2000
Formats:txt pdf
Obsoletes:RFC 2052
Updated by:RFC 6335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2782
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.
 
RFC 2784 Generic Routing Encapsulation (GRE)
 
Authors:D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina.
Date:March 2000
Formats:txt pdf
Updated by:RFC 2890
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2784
This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
 
RFC 2798 Definition of the inetOrgPerson LDAP Object Class
 
Authors:M. Smith.
Date:April 2000
Formats:txt pdf
Updated by:RFC 3698, RFC 4519, RFC 4524
Status:INFORMATIONAL
DOI:10.17487/RFC 2798
While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs.
 
RFC 2817 Upgrading to TLS Within HTTP/1.1
 
Authors:R. Khare, S. Lawrence.
Date:May 2000
Formats:txt pdf
Updates:RFC 2616
Updated by:RFC 7230, RFC 7231
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2817
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP +TLS server can disambiguate traffic intended for several hostnames at a single IP address.

Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes newIANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.

This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace(http://example.org/ and https://example.org/ are not equivalent).

 
RFC 2818 HTTP Over TLS
 
Authors:E. Rescorla.
Date:May 2000
Formats:txt pdf
Updated by:RFC 5785, RFC 7230
Status:INFORMATIONAL
DOI:10.17487/RFC 2818
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
 
Authors:J. Klensin, Ed..
Date:April 2001
Formats:txt pdf
Obsoletes:RFC 0821, RFC 0974, RFC 1869
Obsoleted by:RFC 5321
Updated by:RFC 5336
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2821
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
 
Authors:P. Resnick, Ed..
Date:April 2001
Formats:txt pdf
Obsoletes:RFC 0822
Obsoleted by:RFC 5322
Updated by:RFC 5335, RFC 5336
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2822
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
 
RFC 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
 
Authors:P. Ferguson, D. Senie.
Date:May 2000
Formats:txt pdf
Obsoletes:RFC 2267
Updated by:RFC 3704
Also:BCP 0038
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2827
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.
 
RFC 2829 Authentication Methods for LDAP
 
Authors:M. Wahl, H. Alvestrand, J. Hodges, R. Morgan.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4513, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2829
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
 
Authors:J. Hodges, R. Morgan, M. Wahl.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4511, RFC 4513, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2830
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request.
 
RFC 2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0
 
Authors:S. Hollenbeck, M. Srivastava.
Date:May 2000
Formats:txt pdf
Updated by:RFC 3632
Status:INFORMATIONAL
DOI:10.17487/RFC 2832
This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry.

Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services.

This document is being discussed on the "rrp" mailing list. To join the list, send a message to <majordomo@NSIRegistry.com&rt; with the words "subscribe rrp" in the body of the message. There is also a web site for the mailing list archives at<http://www.NSIRegistry.net/maillist/rrp&rt;.

 
RFC 2834 ARP and IP Broadcast over HIPPI-800
 
Authors:J.-M. Pittet.
Date:May 2000
Formats:txt pdf
Obsoletes:RFC 1374
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2834
This document specifies a method for resolving IP addresses to ANSIHigh-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte SystemNetwork, GSN). This document (when combined with RFC-2067 "IP overHIPPI") obsoletes RFC-1374.
 
RFC 2835 IP and ARP over HIPPI-6400 (GSN)
 
Authors:J.-M. Pittet.
Date:May 2000
Formats:txt pdf
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2835
The ANSI T11.1 task force has standardized HIPPI-6400 also known asGigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified inHIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].

HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs[10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks.

 
RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
 
Authors:P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington.
Date:May 2000
Formats:txt pdf
Updates:RFC 1035
Updated by:RFC 3645, RFC 4635, RFC 6895
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2845
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.

No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available.

 
RFC 2846 GSTN Address Element Extensions in E-mail Services
 
Authors:C. Allocchio.
Date:June 2000
Formats:txt pdf
Updated by:RFC 3191, RFC 3192
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2846
There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in[1].
 
RFC 2865 Remote Authentication Dial In User Service (RADIUS)
 
Authors:C. Rigney, S. Willens, A. Rubens, W. Simpson.
Date:June 2000
Formats:txt pdf
Obsoletes:RFC 2138
Updated by:RFC 2868, RFC 3575, RFC 5080, RFC 6929, RFC 8044
Status:DRAFT STANDARD
DOI:10.17487/RFC 2865
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.
 
RFC 2866 RADIUS Accounting
 
Authors:C. Rigney.
Date:June 2000
Formats:txt pdf
Obsoletes:RFC 2139
Updated by:RFC 2867, RFC 5080, RFC 5997
Status:INFORMATIONAL
DOI:10.17487/RFC 2866
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.
 
RFC 2868 RADIUS Attributes for Tunnel Protocol Support
 
Authors:G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret.
Date:June 2000
Formats:txt pdf
Updates:RFC 2865
Updated by:RFC 3575
Status:INFORMATIONAL
DOI:10.17487/RFC 2868
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
 
RFC 2869 RADIUS Extensions
 
Authors:C. Rigney, W. Willats, P. Calhoun.
Date:June 2000
Formats:txt pdf
Updated by:RFC 3579, RFC 5080
Status:INFORMATIONAL
DOI:10.17487/RFC 2869
This document describes additional attributes for carrying authentication, authorization and accounting information between aNetwork Access Server (NAS) and a shared Accounting Server using theRemote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2].
 
RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering
 
Authors:M. Crawford, C. Huitema.
Date:July 2000
Formats:txt pdf
Updates:RFC 1886
Updated by:RFC 3152, RFC 3226, RFC 3363, RFC 3364
Status:HISTORIC
DOI:10.17487/RFC 2874
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.

For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.

 
RFC 2895 Remote Network Monitoring MIB Protocol Identifier Reference
 
Authors:A. Bierman, C. Bucci, R. Iddon.
Date:August 2000
Formats:txt pdf
Obsoletes:RFC 2074
Updated by:RFC 3395
Status:DRAFT STANDARD
DOI:10.17487/RFC 2895
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network MonitoringManagement Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.

The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON ProtocolIdentifier Macros document [RFC2896] now contains the non-normative portion of that specification.

This document obsoletes RFC 2074.

 
RFC 2910 Internet Printing Protocol/1.1: Encoding and Transport
 
Authors:R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn.
Date:September 2000
Formats:txt pdf
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
 
Authors:T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell.
Date:September 2000
Formats:txt pdf
Obsoletes:RFC 2566
Obsoleted by:RFC 8011
Updated by:RFC 3380, RFC 3382, RFC 3996, RFC 3995, RFC 7472
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2911
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics (this document)Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]Mapping between LPD and IPP Protocols [RFC2569]

The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.

The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.

The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called"application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.

The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.

The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2914 Congestion Control Principles
 
Authors:S. Floyd.
Date:September 2000
Formats:txt pdf
Updated by:RFC 7141
Also:BCP 0041
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2914
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols.
 
RFC 2918 Route Refresh Capability for BGP-4
 
Authors:E. Chen.
Date:September 2000
Formats:txt pdf
Updated by:RFC 7313
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2918
This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes.
 
RFC 2930 Secret Key Establishment for DNS (TKEY RR)
 
Authors:D. Eastlake 3rd.
Date:September 2000
Formats:txt pdf
Updated by:RFC 6895
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2930
[RFC 2845] provides a means of authenticating Domain Name System(DNS) queries and responses using shared secret keys via theTransaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.
 
RFC 2960 Stream Control Transmission Protocol
 
Authors:R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson.
Date:October 2000
Formats:txt pdf
Obsoleted by:RFC 4960
Updated by:RFC 3309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2960
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

 
RFC 2961 RSVP Refresh Overhead Reduction Extensions
 
Authors:L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini.
Date:April 2001
Formats:txt pdf
Updated by:RFC 5063
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2961
This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP(Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages.The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.
 
RFC 2980 Common NNTP Extensions
 
Authors:S. Barber.
Date:October 2000
Formats:txt pdf
Updated by:RFC 3977, RFC 4643, RFC 4644, RFC 6048
Status:INFORMATIONAL
DOI:10.17487/RFC 2980
In this document, a number of popular extensions to the Network NewsTransfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions.
 
RFC 2986 PKCS #10: Certification Request Syntax Specification Version 1.7
 
Authors:M. Nystrom, B. Kaliski.
Date:November 2000
Formats:txt pdf
Obsoletes:RFC 2314
Updated by:RFC 5967
Status:INFORMATIONAL
DOI:10.17487/RFC 2986
This memo represents a republication of PKCS #10 v1.7 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.

This memo describes a syntax for certification requests.

 
RFC 3008 Domain Name System Security (DNSSEC) Signing Authority
 
Authors:B. Wellington.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 4035, RFC 4033, RFC 4034
Updates:RFC 2535
Updated by:RFC 3658
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3008
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 3023 XML Media Types
 
Authors:M. Murata, S. St. Laurent, D. Kohn.
Date:January 2001
Formats:txt pdf
Obsoletes:RFC 2376
Obsoleted by:RFC 7303
Updates:RFC 2048
Updated by:RFC 6839
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3023
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.

Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be".

 
RFC 3031 Multiprotocol Label Switching Architecture
 
Authors:E. Rosen, A. Viswanathan, R. Callon.
Date:January 2001
Formats:txt pdf
Updated by:RFC 6178, RFC 6790
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3031
This document specifies the architecture for Multiprotocol LabelSwitching (MPLS).
 
RFC 3032 MPLS Label Stack Encoding
 
Authors:E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta.
Date:January 2001
Formats:txt pdf
Updated by:RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3032
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.
 
RFC 3038 VCID Notification over ATM link for LDP
 
Authors:K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan.
Date:January 2001
Formats:txt pdf
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3038
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
 
RFC 3046 DHCP Relay Agent Information Option
 
Authors:M. Patrick.
Date:January 2001
Formats:txt pdf
Updated by:RFC 6607
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3046
Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use theDynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.However, a number of security and scaling problems arise with such"public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132.

The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originatedDHCP packets to a DHCP server. Servers recognizing the Relay AgentInformation option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.

The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem.

 
RFC 3057 ISDN Q.921-User Adaptation Layer
 
Authors:K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom.
Date:February 2001
Formats:txt pdf
Obsoleted by:RFC 4233
Updated by:RFC 3807
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3057
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
 
RFC 3060 Policy Core Information Model -- Version 1 Specification
 
Authors:B. Moore, E. Ellesson, J. Strassner, A. Westerinen.
Date:February 2001
Formats:txt pdf
Updated by:RFC 3460
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3060
This document presents the object-oriented information model for representing policy information developed jointly in the IETF PolicyFramework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol.
 
RFC 3090 DNS Security Extension Clarification on Zone Status
 
Authors:E. Lewis.
Date:March 2001
Formats:txt pdf
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 2535
Updated by:RFC 3658
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3090
The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.
 
RFC 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
 
Authors:C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng.
Date:July 2001
Formats:txt pdf
Updated by:RFC 3759, RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3095
This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol), UDP/IP, and ESP/IP(Encapsulating Security Payload) headers.

Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common.

This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards trackMobile IPv6 has been completed.

 
RFC 3106 ECML v1.1: Field Specifications for E-Commerce
 
Authors:D. Eastlake 3rd, T. Goldstein.
Date:April 2001
Formats:txt pdf
Obsoletes:RFC 2706
Updated by:RFC 4112
Status:INFORMATIONAL
DOI:10.17487/RFC 3106
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication.
 
RFC 3107 Carrying Label Information in BGP-4
 
Authors:Y. Rekhter, E. Rosen.
Date:May 2001
Formats:txt pdf
Obsoleted by:RFC 8277
Updated by:RFC 6790
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3107
This document specifies the way in which the label mapping information for a particular route is piggybacked in the same BorderGateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching(MPLS) label which is mapped to that route.
 
RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:May 2001
Formats:txt pdf
Obsoletes:RFC 2537
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3110
This document describes how to produce RSA/SHA1 SIG resource records(RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2.

Since the adoption of a Proposed Standard for RSA signatures in theDNS (Domain Name Space), advances in hashing have been made. A newDNS signature algorithm is defined to make these advances available in SIG RRs. The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made toDNS security.

 
RFC 3146 Transmission of IPv6 Packets over IEEE 1394 Networks
 
Authors:K. Fujisawa, A. Onoe.
Date:October 2001
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3146
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
 
RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
 
Authors:C. Adams, P. Cain, D. Pinkas, R. Zuccherato.
Date:August 2001
Formats:txt pdf
Updated by:RFC 5816
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3161
This document describes the format of a request sent to a TimeStamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses.
 
RFC 3162 RADIUS and IPv6
 
Authors:B. Aboba, G. Zorn, D. Mitton.
Date:August 2001
Formats:txt pdf
Updated by:RFC 8044
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3162
This document specifies the operation of RADIUS (RemoteAuthentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access.
 
RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP
 
Authors:K. Ramakrishnan, S. Floyd, D. Black.
Date:September 2001
Formats:txt pdf
Obsoletes:RFC 2481
Updates:RFC 2003, RFC 2474, RFC 2401, RFC 0793
Updated by:RFC 4301, RFC 6040, RFC 8311
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3168
This memo specifies the incorporation of ECN (Explicit CongestionNotification) to TCP and IP, including ECN's use of two bits in theIP header.
 
RFC 3174 US Secure Hash Algorithm 1 (SHA1)
 
Authors:D. Eastlake 3rd, P. Jones.
Date:September 2001
Formats:txt pdf
Updated by:RFC 4634, RFC 6234
Status:INFORMATIONAL
DOI:10.17487/RFC 3174
The purpose of this document is to make the SHA-1 (Secure HashAlgorithm 1) hash algorithm conveniently available to the Internet community. The United States of America has adopted the SHA-1 hash algorithm described herein as a Federal Information ProcessingStandard. Most of the text herein was taken by the authors from FIPS180-1. Only the C code implementation is "original".
 
RFC 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations
 
Authors:F. Baker, C. Iturralde, F. Le Faucheur, B. Davie.
Date:September 2001
Formats:txt pdf
Updated by:RFC 5350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3175
This document describes the use of a single RSVP (ResourceReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM(Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.
 
RFC 3203 DHCP reconfigure extension
 
Authors:Y. T'Joens, C. Hublet, P. De Schrijver.
Date:December 2001
Formats:txt pdf
Updated by:RFC 6704
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3203
This document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described.
 
RFC 3204 MIME media types for ISUP and QSIG Objects
 
Authors:E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun.
Date:December 2001
Formats:txt pdf
Updated by:RFC 3459, RFC 5621
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3204
This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identifyISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN.
 
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security
 
Authors:P. Hoffman.
Date:February 2002
Formats:txt pdf
Obsoletes:RFC 2487
Updated by:RFC 7817
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3207
This document describes an extension to the SMTP (Simple MailTransfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.
 
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
 
Authors:D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow.
Date:December 2001
Formats:txt pdf
Updated by:RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3209
This document describes the use of RSVP (Resource ReservationProtocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.

We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.

 
RFC 3212 Constraint-Based LSP Setup using LDP
 
Authors:B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis.
Date:January 2002
Formats:txt pdf
Updated by:RFC 3468, RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3212
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol).

This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP.

 
RFC 3225 Indicating Resolver Support of DNSSEC
 
Authors:D. Conrad.
Date:December 2001
Formats:txt pdf
Updated by:RFC 4033, RFC 4034, RFC 4035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3225
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.
 
RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements
 
Authors:O. Gudmundsson.
Date:December 2001
Formats:txt pdf
Updates:RFC 2535, RFC 2874
Updated by:RFC 4033, RFC 4034, RFC 4035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3226
This document mandates support for EDNS0 (Extension Mechanisms forDNS) in DNS entities claiming to support either DNS SecurityExtensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updatesRFC 2535 and RFC 2874, by adding new requirements.
 
RFC 3241 Robust Header Compression (ROHC) over PPP
 
Authors:C. Bormann.
Date:April 2002
Formats:txt pdf
Updates:RFC 1332
Updated by:RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3241
This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over thePoint-to-Point Protocol (PPP). It defines extensions to the PPPControl Protocols for IPv4 and IPv6.
 
RFC 3261 SIP: Session Initiation Protocol
 
Authors:J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler.
Date:June 2002
Formats:txt pdf
Obsoletes:RFC 2543
Updated by:RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3261
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.

SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types.SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.

 
RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:June 2002
Formats:txt pdf
Obsoletes:RFC 2543
Updated by:RFC 7984
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3263
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
 
RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:June 2002
Formats:txt pdf
Obsoletes:RFC 2543
Updated by:RFC 6157
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3264
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol(SIP).
 
RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
 
Authors:A. B. Roach.
Date:June 2002
Formats:txt pdf
Obsoletes:RFC 2543
Obsoleted by:RFC 6665
Updates:RFC 3261
Updated by:RFC 5367, RFC 5727, RFC 6446
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3265
This document describes an extension to the Session InitiationProtocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

Concrete uses of the mechanism described in this document may be standardized in the future.

Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.

 
RFC 3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
 
Authors:F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen.
Date:May 2002
Formats:txt pdf
Updates:RFC 3032
Updated by:RFC 5462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3270
This document defines a flexible solution for support ofDifferentiated Services (Diff-Serv) over Multi-Protocol LabelSwitching (MPLS) networks.

This solution allows the MPLS network administrator to select howDiff-Serv Behavior Aggregates (BAs) are mapped onto Label SwitchedPaths (LSPs) so that he/she can best match the Diff-Serv, TrafficEngineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.

 
RFC 3272 Overview and Principles of Internet Traffic Engineering
 
Authors:D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao.
Date:May 2002
Formats:txt pdf
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3272
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.
 
RFC 3273 Remote Network Monitoring Management Information Base for High Capacity Networks
 
Authors:S. Waldbusser.
Date:July 2002
Formats:txt pdf
Updated by:RFC 4502
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3273
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021.
 
RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
 
Authors:L. Bassham, W. Polk, R. Housley.
Date:April 2002
Formats:txt pdf
Updated by:RFC 4055, RFC 4491, RFC 5480, RFC 5758
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3279
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in theInternet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs).Certificates include the public key of the named subject.
 
RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
 
Authors:R. Housley, W. Polk, W. Ford, D. Solo.
Date:April 2002
Formats:txt pdf
Obsoletes:RFC 2459
Obsoleted by:RFC 5280
Updated by:RFC 4325, RFC 4630
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3280
This memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. AnASN.1 module and examples are provided in the appendices.
 
RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses
 
Authors:B. Haberman, D. Thaler.
Date:August 2002
Formats:txt pdf
Updated by:RFC 3956, RFC 4489, RFC 7371
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3306
This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol.
 
RFC 3312 Integration of Resource Management and Session Initiation Protocol (SIP)
 
Authors:G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg.
Date:October 2002
Formats:txt ps pdf
Updated by:RFC 4032, RFC 5027
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3312
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session InitiationProtocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
 
RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
 
Authors:R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney.
Date:July 2003
Formats:txt pdf
Obsoleted by:RFC 8415
Updated by:RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3315
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
 
RFC 3320 Signaling Compression (SigComp)
 
Authors:R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg.
Date:January 2003
Formats:txt pdf
Updated by:RFC 4896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3320
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as theSession Initiation Protocol (SIP) (RFC 3261) and the Real TimeStreaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of theSigComp message.

Decompression functionality for SigComp is provided by a UniversalDecompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).

 
RFC 3321 Signaling Compression (SigComp) - Extended Operations
 
Authors:H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price.
Date:January 2003
Formats:txt pdf
Updated by:RFC 4896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3321
This document describes how to implement certain mechanisms inSignaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per- message compression.

SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC3320.

 
RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
 
Authors:C. Jennings, J. Peterson, M. Watson.
Date:November 2002
Formats:txt pdf
Updated by:RFC 5876, RFC 8217
Status:INFORMATIONAL
DOI:10.17487/RFC 3325
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.
 
RFC 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
 
Authors:D. Willis, B. Hoeneisen.
Date:December 2002
Formats:txt pdf
Updated by:RFC 5626
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3327
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of aUniform Resource Identifier (URI), such as Contact:<sip:alice@pc33.atlanta.com&rt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.
 
RFC 3344 IP Mobility Support for IPv4
 
Authors:C. Perkins, Ed..
Date:August 2002
Formats:txt pdf
Obsoletes:RFC 3220
Obsoleted by:RFC 5944
Updated by:RFC 4636, RFC 4721
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3344
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
 
RFC 3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
 
Authors:R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain.
Date:August 2002
Formats:txt pdf
Updates:RFC 2673, RFC 2874
Updated by:RFC 6672
Status:INFORMATIONAL
DOI:10.17487/RFC 3363
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.
 
RFC 3370 Cryptographic Message Syntax (CMS) Algorithms
 
Authors:R. Housley.
Date:August 2002
Formats:txt pdf
Obsoletes:RFC 2630, RFC 3211
Updated by:RFC 5754
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3370
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS).The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
 
RFC 3376 Internet Group Management Protocol, Version 3
 
Authors:B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan.
Date:October 2002
Formats:txt pdf
Updates:RFC 2236
Updated by:RFC 4604
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3376
This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets*only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.

This document obsoletes RFC 2236.

 
RFC 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
 
Authors:D. Harrington, R. Presuhn, B. Wijnen.
Date:December 2002
Formats:txt pdf
Obsoletes:RFC 2571
Updated by:RFC 5343, RFC 5590
Also:STD 0062
Status:INTERNET STANDARD
DOI:10.17487/RFC 3411
This document describes an architecture for describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are anSNMP engine containing a Message Processing Subsystem, a SecuritySubsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571.
 
RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
 
Authors:J. Case, D. Harrington, R. Presuhn, B. Wijnen.
Date:December 2002
Formats:txt pdf
Obsoletes:RFC 2572
Updated by:RFC 5590
Also:STD 0062
Status:INTERNET STANDARD
DOI:10.17487/RFC 3412
This document describes the Message Processing and Dispatching forSimple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP MessageProcessing Models, and for dispatching PDUs to SNMP applications.This document also describes one Message Processing Model - theSNMPv3 Message Processing Model. This document obsoletes RFC 2572.
 
RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
 
Authors:U. Blumenthal, B. Wijnen.
Date:December 2002
Formats:txt pdf
Obsoletes:RFC 2574
Updated by:RFC 5590
Also:STD 0062
Status:INTERNET STANDARD
DOI:10.17487/RFC 3414
This document describes the User-based Security Model (USM) forSimple Network Management Protocol (SNMP) version 3 for use in theSNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes aManagement Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574.
 
RFC 3417 Transport Mappings for the Simple Network Management Protocol (SNMP)
 
Authors:R. Presuhn, Ed..
Date:December 2002
Formats:txt pdf
Obsoletes:RFC 1906
Updated by:RFC 4789, RFC 5590
Also:STD 0062
Status:INTERNET STANDARD
DOI:10.17487/RFC 3417
This document defines the transport of Simple Network ManagementProtocol (SNMP) messages over various protocols. This document obsoletes RFC 1906.
 
RFC 3427 Change Process for the Session Initiation Protocol (SIP)
 
Authors:A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen.
Date:December 2002
Formats:txt pdf
Obsoleted by:RFC 5727
Updated by:RFC 3968, RFC 3969
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3427
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions.
 
RFC 3435 Media Gateway Control Protocol (MGCP) Version 1.0
 
Authors:F. Andreasen, B. Foster.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 2705
Updated by:RFC 3661
Status:INFORMATIONAL
DOI:10.17487/RFC 3435
This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control"intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.

Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.

The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents.

 
RFC 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
 
Authors:P. Agarwal, B. Akyol.
Date:January 2003
Formats:txt pdf
Updates:RFC 3032
Updated by:RFC 5462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3443
This document describes Time To Live (TTL) processing in hierarchicalMulti-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label StackEncoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and"pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks.
 
RFC 3458 Message Context for Internet Mail
 
Authors:E. Burger, E. Candell, C. Eliot, G. Klyne.
Date:January 2003
Formats:txt pdf
Updated by:RFC 3938
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3458
This memo describes a new RFC 2822 message header, "Message-Context".This header provides information about the context and presentation characteristics of a message.

A receiving user agent (UA) may use this information as a hint to optimally present the message.

 
RFC 3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
 
Authors:E. Burger.
Date:January 2003
Formats:txt pdf
Updates:RFC 3204
Updated by:RFC 5621
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3459
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.

By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward.It can indicate how hard a gateway should try to deliver a body part.It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process.

 
RFC 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
 
Authors:K. Moore.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1891
Updated by:RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098
Status:DRAFT STANDARD
DOI:10.17487/RFC 3461
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service, which allows an SMTP client to specify (a) thatDelivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
 
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
 
Authors:G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1892
Obsoleted by:RFC 6522
Updated by:RFC 5337
Status:DRAFT STANDARD
DOI:10.17487/RFC 3462
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.

This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.

 
RFC 3463 Enhanced Mail System Status Codes
 
Authors:G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1893
Updated by:RFC 3886, RFC 4468, RFC 4865, RFC 4954, RFC 5248
Status:DRAFT STANDARD
DOI:10.17487/RFC 3463
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in theDelivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status.
 
RFC 3464 An Extensible Message Format for Delivery Status Notifications
 
Authors:K. Moore, G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1894
Updated by:RFC 4865, RFC 5337, RFC 6533
Status:DRAFT STANDARD
DOI:10.17487/RFC 3464
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network(LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.

 
RFC 3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
 
Authors:V. Sharma, Ed., F. Hellstrand, Ed..
Date:February 2003
Formats:txt pdf
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3469
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework.
 
RFC 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
 
Authors:L. Berger, Ed..
Date:January 2003
Formats:txt pdf
Updated by:RFC 4201, RFC 4328, RFC 4872, RFC 6002, RFC 6003, RFC 6205, RFC 7074, RFC 7699, RFC 8359
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3471
This document describes extensions to Multi-Protocol Label Switching(MPLS) signaling required to support Generalized MPLS. GeneralizedMPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
 
RFC 3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
 
Authors:P. Ashwood-Smith, Ed., L. Berger, Ed..
Date:January 2003
Formats:txt pdf
Updated by:RFC 3468, RFC 4201
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3472
This document describes extensions to Multi-Protocol Label Switching(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.
 
RFC 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
 
Authors:L. Berger, Ed..
Date:January 2003
Formats:txt pdf
Updated by:RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003, RFC 6780, RFC 8359
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3473
This document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.
 
RFC 3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)
 
Authors:O. Aboul-Magd.
Date:March 2003
Formats:txt pdf
Updated by:RFC 3468
Status:INFORMATIONAL
DOI:10.17487/RFC 3475
Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by theIETF in the context of Generalized Multi-Protocol Label Switching(GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents.
 
RFC 3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling
 
Authors:B. Rajagopalan.
Date:March 2003
Formats:txt pdf
Updated by:RFC 3468
Status:INFORMATIONAL
DOI:10.17487/RFC 3476
The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource ReSerVationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new data objects and error codes. This document describes these extensions.
 
RFC 3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
 
Authors:K. Kompella, Y. Rekhter.
Date:January 2003
Formats:txt pdf
Updated by:RFC 6107
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3477
Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to ResourceReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels(RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.
 
RFC 3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
 
Authors:M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach.
Date:February 2003
Formats:txt pdf
Updated by:RFC 4896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3485
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent.
 
RFC 3486 Compressing the Session Initiation Protocol (SIP)
 
Authors:G. Camarillo.
Date:February 2003
Formats:txt pdf
Updated by:RFC 5049
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3486
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages.It also states when it is appropriate to send compressed SIP messages to a SIP entity.
 
RFC 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
 
Authors:A. Costello.
Date:March 2003
Formats:txt pdf
Updated by:RFC 5891
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3492
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm calledBootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA.
 
RFC 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
 
Authors:M. Crispin.
Date:March 2003
Formats:txt pdf
Obsoletes:RFC 2060
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
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3501
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.

IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers.These numbers are either message sequence numbers or unique identifiers.

IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.

IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.

 
RFC 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
 
Authors:M. Crispin.
Date:March 2003
Formats:txt pdf
Updated by:RFC 4466, RFC 4469
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3502
This document describes the multiappending extension to the InternetMessage Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.

A server which supports this extension indicates this with a capability name of "MULTIAPPEND".

 
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
 
Authors:R. Sparks.
Date:April 2003
Formats:txt pdf
Updated by:RFC 7647, RFC 8217
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3515
This document defines the REFER method. This Session InitiationProtocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.

In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.

 
RFC 3516 IMAP4 Binary Content Extension
 
Authors:L. Nerenberg.
Date:April 2003
Formats:txt pdf
Updated by:RFC 4466
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3516
This memo defines the Binary extension to the Internet Message AccessProtocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content- transfer-encoding.
 
RFC 3550 RTP: A Transport Protocol for Real-Time Applications
 
Authors:H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.
Date:July 2003
Formats:txt ps pdf
Obsoletes:RFC 1889
Updated by:RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108
Also:STD 0064
Status:INTERNET STANDARD
DOI:10.17487/RFC 3550
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP andRTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.

Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.

 
RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control
 
Authors:H. Schulzrinne, S. Casner.
Date:July 2003
Formats:txt ps pdf
Obsoletes:RFC 1890
Updated by:RFC 5761, RFC 7007
Also:STD 0065
Status:INTERNET STANDARD
DOI:10.17487/RFC 3551
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.

This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.

This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.

 
RFC 3555 MIME Type Registration of RTP Payload Formats
 
Authors:S. Casner, P. Hoschka.
Date:July 2003
Formats:txt pdf
Obsoleted by:RFC 4855, RFC 4856
Updated by:RFC 3625, RFC 4629
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3555
This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences asMIME subtypes. Some of these may also be used for transfer modes other than RTP.
 
RFC 3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)
 
Authors:A. Li.
Date:July 2003
Formats:txt pdf
Updated by:RFC 4788
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3558
This document describes the RTP payload format for Enhanced VariableRate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech.Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications.
 
RFC 3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development
 
Authors:A. Zinin.
Date:July 2003
Formats:txt pdf
Updated by:RFC 6233
Status:INFORMATIONAL
DOI:10.17487/RFC 3563
This document contains the text of the agreement signed betweenISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines.
 
RFC 3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering
 
Authors:F. Le Faucheur, W. Lai.
Date:July 2003
Formats:txt pdf
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3564
This document presents Service Provider requirements for support ofDifferentiated Services (Diff-Serv)-aware MPLS Traffic Engineering(DS-TE).

Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.

A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short andDiff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.

 
RFC 3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
 
Authors:T. Ogura, M. Maruyama, T. Yoshida.
Date:July 2003
Formats:txt pdf
Updated by:RFC 8064
Status:INFORMATIONAL
DOI:10.17487/RFC 3572
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy(SONET/SDH).

This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of formingIPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.

 
RFC 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service)
 
Authors:B. Aboba.
Date:July 2003
Formats:txt pdf
Updates:RFC 2865, RFC 2868
Updated by:RFC 6929
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3575
This document describes the IANA considerations for the RemoteAuthentication Dial In User Service (RADIUS).

This document updates RFC 2865.

 
RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
 
Authors:B. Aboba, P. Calhoun.
Date:September 2003
Formats:txt pdf
Updates:RFC 2869
Updated by:RFC 5080
Status:INFORMATIONAL
DOI:10.17487/RFC 3579
This document defines Remote Authentication Dial In User Service(RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. WhileEAP was originally developed for use with PPP, it is now also in use with IEEE 802.

This document updates RFC 2869.

 
RFC 3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
 
Authors:P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese.
Date:September 2003
Formats:txt pdf
Updated by:RFC 7268
Status:INFORMATIONAL
DOI:10.17487/RFC 3580
This document provides suggestions on Remote Authentication Dial InUser Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normativeAppendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.
 
RFC 3588 Diameter Base Protocol
 
Authors:P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko.
Date:September 2003
Formats:txt pdf
Obsoleted by:RFC 6733
Updated by:RFC 5729, RFC 5719, RFC 6408
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3588
The Diameter base protocol is intended to provide an Authentication,Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by allDiameter applications. The Diameter base application needs to be supported by all Diameter implementations.
 
RFC 3597 Handling of Unknown DNS Resource Record (RR) Types
 
Authors:A. Gustafsson.
Date:September 2003
Formats:txt pdf
Updates:RFC 2163, RFC 2535
Updated by:RFC 4033, RFC 4034, RFC 4035, RFC 5395, RFC 6195, RFC 6895
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3597
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.
 
RFC 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
 
Authors:D. Willis, B. Hoeneisen.
Date:October 2003
Formats:txt pdf
Updated by:RFC 5630
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3608
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.
 
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2
 
Authors:D. Katz, K. Kompella, D. Yeung.
Date:September 2003
Formats:txt pdf
Updates:RFC 2370
Updated by:RFC 4203, RFC 5786
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3630
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link StateAdvertisements.
 
RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6
 
Authors:O. Troan, R. Droms.
Date:December 2003
Formats:txt pdf
Obsoleted by:RFC 8415
Updated by:RFC 6603, RFC 7550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3633
The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host ConfigurationProtocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.
 
RFC 3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams
 
Authors:J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric.
Date:November 2003
Formats:txt pdf
Updated by:RFC 5691
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3640
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29WG11) is a working group in ISO that produced the MPEG-4 standard.MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non- multiplexed MPEG-4 elementary stream.
 
RFC 3641 Generic String Encoding Rules (GSER) for ASN.1 Types
 
Authors:S. Legg.
Date:October 2003
Formats:txt pdf
Updated by:RFC 4792
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3641
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.
 
RFC 3658 Delegation Signer (DS) Resource Record (RR)
 
Authors:O. Gudmundsson.
Date:December 2003
Formats:txt pdf
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 3090, RFC 3008, RFC 2535, RFC 1035
Updated by:RFC 3755
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3658
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.

This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090.

 
RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations
 
Authors:J. Rosenberg.
Date:March 2004
Formats:txt pdf
Updated by:RFC 6140
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3680
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations.Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
 
RFC 3693 Geopriv Requirements
 
Authors:J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk.
Date:February 2004
Formats:txt pdf
Updated by:RFC 6280, RFC 7459
Status:INFORMATIONAL
DOI:10.17487/RFC 3693
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.

This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.

 
RFC 3694 Threat Analysis of the Geopriv Protocol
 
Authors:M. Danley, D. Mulligan, J. Morris, J. Peterson.
Date:February 2004
Formats:txt pdf
Updated by:RFC 6280
Status:INFORMATIONAL
DOI:10.17487/RFC 3694
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements.
 
RFC 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules
 
Authors:K. Zeilenga, Ed..
Date:February 2004
Formats:txt pdf
Updates:RFC 2798
Updated by:RFC 4517
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3698
This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use.
 
RFC 3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema
 
Authors:J. Strassner, B. Moore, R. Moats, E. Ellesson.
Date:February 2004
Formats:txt pdf
Updated by:RFC 4104
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3703
This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that usesLightweight Directory Access Protocol (LDAP) as its access protocol.This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them.
 
RFC 3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
 
Authors:S. Santesson, R. Housley, T. Freeman.
Date:February 2004
Formats:txt pdf
Updated by:RFC 6170
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3709
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.
 
RFC 3710 An IESG charter
 
Authors:H. Alvestrand.
Date:February 2004
Formats:txt pdf
Updated by:RFC 3932, RFC 5742
Status:INFORMATIONAL
DOI:10.17487/RFC 3710
This memo provides a charter for the Internet Engineering SteeringGroup (IESG), a management function of the Internet Engineering TaskForce (IETF). It is meant to document the charter of the IESG as it is presently understood.
 
RFC 3711 The Secure Real-time Transport Protocol (SRTP)
 
Authors:M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman.
Date:March 2004
Formats:txt pdf
Updated by:RFC 5506, RFC 6904
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3711
This document describes the Secure Real-time Transport Protocol(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, theReal-time Transport Control Protocol (RTCP).
 
RFC 3720 Internet Small Computer Systems Interface (iSCSI)
 
Authors:J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner.
Date:April 2004
Formats:txt pdf
Obsoleted by:RFC 7143
Updated by:RFC 3980, RFC 4850, RFC 5048, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3720
This document describes a transport protocol for Internet SmallComputer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.

SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).

As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI.

 
RFC 3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery
 
Authors:M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger.
Date:April 2004
Formats:txt pdf
Updated by:RFC 7143
Status:INFORMATIONAL
DOI:10.17487/RFC 3721
This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.
 
RFC 3723 Securing Block Storage Protocols over IP
 
Authors:B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino.
Date:April 2004
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3723
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small ComputerSystem Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (InternetStorage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.
 
RFC 3748 Extensible Authentication Protocol (EAP)
 
Authors:B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed..
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2284
Updated by:RFC 5247, RFC 7057
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3748
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such asPoint-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.Fragmentation is not supported within EAP itself; however, individualEAP methods may support this.

This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.

 
RFC 3749 Transport Layer Security Protocol Compression Methods
 
Authors:S. Hollenbeck.
Date:May 2004
Formats:txt pdf
Updated by:RFC 8447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3749
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use withTLS, and it describes a method for the specification of additionalTLS compression methods.
 
RFC 3755 Legacy Resolver Compatibility for Delegation Signer (DS)
 
Authors:S. Weiler.
Date:May 2004
Formats:txt pdf
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 3658, RFC 2535
Updated by:RFC 3757, RFC 3845
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3755
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
 
RFC 3762 Telephone Number Mapping (ENUM) Service Registration for H.323
 
Authors:O. Levin.
Date:April 2004
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3762
The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone NumberMapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761.
 
RFC 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record
 
Authors:J. Peterson.
Date:April 2004
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3764
This document registers an Electronic Number (ENUM) service for theSession Initiation Protocol (SIP), pursuant to the guidelines in RFC3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM.
 
RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
 
Authors:J. Arkko, V. Devarapalli, F. Dupont.
Date:June 2004
Formats:txt pdf
Updated by:RFC 4877
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3776
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
 
RFC 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:J. Galvin, Ed..
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2727
Obsoleted by:RFC 7437
Updated by:RFC 5078, RFC 5633, RFC 5680, RFC 6859
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3777
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication.
 
RFC 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)
 
Authors:H. Smit, T. Li.
Date:June 2004
Formats:txt pdf
Obsoleted by:RFC 5305
Updated by:RFC 4205
Status:INFORMATIONAL
DOI:10.17487/RFC 3784
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
 
RFC 3798 Message Disposition Notification
 
Authors:T. Hansen, Ed., G. Vaudreuil, Ed..
Date:May 2004
Formats:txt pdf
Obsoletes:RFC 2298
Obsoleted by:RFC 8098
Updates:RFC 3461, RFC 2046
Updated by:RFC 5337, RFC 6533
Status:DRAFT STANDARD
DOI:10.17487/RFC 3798
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.

 
RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
 
Authors:R. Vida, Ed., L. Costa, Ed..
Date:June 2004
Formats:txt pdf
Updates:RFC 2710
Updated by:RFC 4604
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3810
This document updates RFC 2710, and it specifies Version 2 of theMulticast Listener Discovery Protocol (MLDv2). MLD is used by anIPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.
 
RFC 3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management
 
Authors:T. Nadeau, Ed., J. Cucchiara, Ed..
Date:June 2004
Formats:txt pdf
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3811
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used MultiprotocolLabel Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.
 
RFC 3821 Fibre Channel Over TCP/IP (FCIP)
 
Authors:M. Rajagopal, E. Rodriguez, R. Weber.
Date:July 2004
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3821
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
 
RFC 3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
 
Authors:D. Peterson.
Date:July 2004
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3822
This document defines the use of Service Location Protocol version 2(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities.
 
RFC 3828 The Lightweight User Datagram Protocol (UDP-Lite)
 
Authors:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed..
Date:July 2004
Formats:txt pdf
Updated by:RFC 6335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3828
This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP.
 
RFC 3830 MIKEY: Multimedia Internet KEYing
 
Authors:J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman.
Date:August 2004
Formats:txt pdf
Updated by:RFC 4738, RFC 6309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3830
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail.

Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols.

 
RFC 3834 Recommendations for Automatic Responses to Electronic Mail
 
Authors:K. Moore.
Date:August 2004
Formats:txt pdf
Updated by:RFC 5436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3834
This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders.The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders.
 
RFC 3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files
 
Authors:R. Castagno, D. Singer.
Date:July 2004
Formats:txt pdf
Updated by:RFC 6381
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3839
This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format.
 
RFC 3843 RObust Header Compression (ROHC): A Compression Profile for IP
 
Authors:L-E. Jonsson, G. Pelletier.
Date:June 2004
Formats:txt pdf
Updated by:RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3843
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload),IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines aROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.
 
RFC 3852 Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 3369
Obsoleted by:RFC 5652
Updated by:RFC 4853, RFC 5083
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3852
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
 
RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism
 
Authors:R. Sparks.
Date:September 2004
Formats:txt pdf
Updated by:RFC 8217
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3892
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI(the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
 
RFC 3920 Extensible Messaging and Presence Protocol (XMPP): Core
 
Authors:P. Saint-Andre, Ed..
Date:October 2004
Formats:txt pdf
Obsoleted by:RFC 6120
Updated by:RFC 6122
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3920
This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
 
RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
 
Authors:J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed..
Date:March 2005
Formats:txt pdf
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3931
This document describes "version 3" of the Layer Two TunnelingProtocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between twoIP nodes. Additional documents detail the specifics for each data link type being emulated.
 
RFC 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture
 
Authors:E. Mannie, Ed..
Date:October 2004
Formats:txt pdf
Updated by:RFC 6002
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3945
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects(PXCs), optical cross-connects (OXCs), etc. that will use GeneralizedMulti-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extendsMPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane.

 
RFC 3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services
 
Authors:J. Peterson.
Date:January 2005
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3953
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning presURIs in ENUM.
 
RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
 
Authors:P. Savola, B. Haberman.
Date:November 2004
Formats:txt pdf
Updates:RFC 3306
Updated by:RFC 7371
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3956
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.
 
RFC 3961 Encryption and Checksum Specifications for Kerberos 5
 
Authors:K. Raeburn.
Date:February 2005
Formats:txt pdf
Updated by:RFC 8429
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3961
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement".
 
RFC 3966 The tel URI for Telephone Numbers
 
Authors:H. Schulzrinne.
Date:December 2004
Formats:txt pdf
Obsoletes:RFC 2806
Updated by:RFC 5341
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3966
This document specifies the URI (Uniform Resource Identifier) scheme"tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806.
 
RFC 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level
 
Authors:R. Bush, T. Narten.
Date:December 2004
Formats:txt pdf
Updated by:RFC 4897, RFC 8067
Also:BCP 0097
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3967
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards orIETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances.
 
RFC 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)
 
Authors:G. Camarillo.
Date:December 2004
Formats:txt pdf
Updates:RFC 3427
Updated by:RFC 5727
Also:BCP 0099
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3969
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS UniformResource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry.
 
RFC 3971 SEcure Neighbor Discovery (SEND)
 
Authors:J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander.
Date:March 2005
Formats:txt pdf
Updated by:RFC 6494, RFC 6495, RFC 6980
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3971
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms forNDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
 
RFC 3972 Cryptographically Generated Addresses (CGA)
 
Authors:T. Aura.
Date:March 2005
Formats:txt pdf
Updated by:RFC 4581, RFC 4982
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3972
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure.
 
RFC 3977 Network News Transfer Protocol (NNTP)
 
Authors:C. Feather.
Date:October 2006
Formats:txt pdf
Obsoletes:RFC 0977
Updates:RFC 2980
Updated by:RFC 6048
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3977
The Network News Transfer Protocol (NNTP) has been in use in theInternet for a decade, and remains one of the most popular protocols(by volume) in use today. This document is a replacement forRFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP.
 
RFC 3978 IETF Rights in Contributions
 
Authors:S. Bradner, Ed..
Date:March 2005
Formats:txt pdf
Obsoletes:RFC 3667
Obsoleted by:RFC 5378
Updates:RFC 2026
Updated by:RFC 4748
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3978
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
 
Authors:S. Bradner, Ed..
Date:March 2005
Formats:txt pdf
Obsoletes:RFC 3668
Obsoleted by:RFC 8179
Updates:RFC 2026, RFC 2028
Updated by:RFC 4879
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3979
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418.
 
RFC 3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol
 
Authors:A. Newton, M. Sanz.
Date:January 2005
Formats:txt pdf
Updated by:RFC 4992
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3981
This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in theExtensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs.
 
RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
 
Authors:S. Bryant, Ed., P. Pate, Ed..
Date:March 2005
Formats:txt pdf
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3985
This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
 
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
 
Authors:T. Berners-Lee, R. Fielding, L. Masinter.
Date:January 2005
Formats:txt pdf
Obsoletes:RFC 2732, RFC 2396, RFC 1808
Updates:RFC 1738
Updated by:RFC 6874, RFC 7320
Also:STD 0066
Status:INTERNET STANDARD
DOI:10.17487/RFC 3986
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on theInternet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
 
RFC 4002 IANA Registration for Enumservice 'web' and 'ft'
 
Authors:R. Brandner, L. Conroy, R. Stastny.
Date:February 2005
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4002
This document registers the Enumservices 'web' and 'ft' by using theURI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761).
 
RFC 4007 IPv6 Scoped Address Architecture
 
Authors:S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill.
Date:March 2005
Formats:txt pdf
Updated by:RFC 7346
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4007
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
 
RFC 4012 Routing Policy Specification Language next generation (RPSLng)
 
Authors:L. Blunk, J. Damas, F. Parent, A. Robachevsky.
Date:March 2005
Formats:txt pdf
Updates:RFC 2725, RFC 2622
Updated by:RFC 7909
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4012
This memo introduces a new set of simple extensions to the RoutingPolicy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet.
 
RFC 4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
 
Authors:M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry.
Date:April 2005
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4018
The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide.
 
RFC 4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
 
Authors:G. Pelletier.
Date:April 2005
Formats:txt pdf
Updated by:RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4019
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.
 
RFC 4021 Registration of Mail and MIME Header Fields
 
Authors:G. Klyne, J. Palme.
Date:March 2005
Formats:txt pdf
Updated by:RFC 5322
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4021
This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864.
 
RFC 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
 
Authors:T. Worster, Y. Rekhter, E. Rosen, Ed..
Date:March 2005
Formats:txt pdf
Updated by:RFC 5332
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4023
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic RoutingEncapsulation). Each of these is applicable in some circumstances.
 
RFC 4033 DNS Security Introduction and Requirements
 
Authors:R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.
Date:March 2005
Formats:txt pdf
Obsoletes:RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Updates:RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226
Updated by:RFC 6014, RFC 6840
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4033
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that theDNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.
 
RFC 4034 Resource Records for the DNS Security Extensions
 
Authors:R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.
Date:March 2005
Formats:txt pdf
Obsoletes:RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Updates:RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226
Updated by:RFC 4470, RFC 6014, RFC 6840, RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4034
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.

 
RFC 4035 Protocol Modifications for the DNS Security Extensions
 
Authors:R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.
Date:March 2005
Formats:txt pdf
Obsoletes:RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Updates:RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226
Updated by:RFC 4470, RFC 6014, RFC 6840, RFC 8198
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4035
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.

 
RFC 4048 RFC 1888 Is Obsolete
 
Authors:B. Carpenter.
Date:April 2005
Formats:txt pdf
Obsoletes:RFC 1888
Updated by:RFC 4548
Status:INFORMATIONAL
DOI:10.17487/RFC 4048
This document recommends that RFC 1888, on Open SystemsInterconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty.
 
RFC 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
 
Authors:J. Schaad, B. Kaliski, R. Housley.
Date:June 2005
Formats:txt pdf
Updates:RFC 3279
Updated by:RFC 5756
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4055
This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric EncryptionPadding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified.
 
RFC 4071 Structure of the IETF Administrative Support Activity (IASA)
 
Authors:R. Austein, Ed., B. Wijnen, Ed..
Date:April 2005
Formats:txt pdf
Updated by:RFC 4371, RFC 7691
Also:BCP 0101
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4071
This document describes the structure of the IETF AdministrativeSupport Activity (IASA) as an activity housed within the InternetSociety (ISOC). It defines the roles and responsibilities of theIETF Administrative Oversight Committee (IAOC), the IETFAdministrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC.
 
RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application
 
Authors:P. Eronen, Ed., T. Hiller, G. Zorn.
Date:August 2005
Formats:txt pdf
Updated by:RFC 7268, RFC 8044
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4072
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server.
 
RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels
 
Authors:P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed..
Date:May 2005
Formats:txt pdf
Updated by:RFC 8271
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4090
This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network.

 
RFC 4102 Registration of the text/red MIME Sub-Type
 
Authors:P. Jones.
Date:June 2005
Formats:txt pdf
Updated by:RFC 6354
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4102
This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198.
 
RFC 4119 A Presence-based GEOPRIV Location Object Format
 
Authors:J. Peterson.
Date:December 2005
Formats:txt pdf
Updated by:RFC 5139, RFC 5491, RFC 7459
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4119
This document describes an object format for carrying geographical information on the Internet. This location object extends thePresence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.
 
RFC 4120 The Kerberos Network Authentication Service (V5)
 
Authors:C. Neuman, T. Yu, S. Hartman, K. Raeburn.
Date:July 2005
Formats:txt pdf
Obsoletes:RFC 1510
Updated by:RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4120
This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.
 
RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
 
Authors:L. Zhu, K. Jaganathan, S. Hartman.
Date:July 2005
Formats:txt pdf
Updates:RFC 1964
Updated by:RFC 6112, RFC 6542, RFC 6649, RFC 8062
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4121
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the KerberosVersion 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles.

 
RFC 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
 
Authors:P. Sarolahti, M. Kojo.
Date:August 2005
Formats:txt pdf
Updated by:RFC 5682
Status:EXPERIMENTAL
DOI:10.17487/RFC 4138
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. TheF-RTO algorithm can also be applied to the Stream ControlTransmission Protocol (SCTP).
 
RFC 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM
 
Authors:K. Toyoda, D. Crocker.
Date:November 2005
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4143
This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.IFax is "facsimile using Internet mail". For this use, the DomainName System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address.
 
RFC 4145 TCP-Based Media Transport in the Session Description Protocol (SDP)
 
Authors:D. Yon, G. Camarillo.
Date:September 2005
Formats:txt pdf
Updated by:RFC 4572
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4145
This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment.
 
RFC 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking
 
Authors:C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards.
Date:September 2005
Formats:txt pdf
Updated by:RFC 6172, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4172
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
 
RFC 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
 
Authors:P. Sarkar, D. Missimer, C. Sapuntzakis.
Date:September 2005
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4173
Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol.The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.
 
RFC 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
 
Authors:C. Monia, J. Tseng, K. Gibbons.
Date:September 2005
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4174
This document describes the Dynamic Host Configuration Protocol(DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre ChannelProtocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network.
 
RFC 4175 RTP Payload Format for Uncompressed Video
 
Authors:L. Gharai, C. Perkins.
Date:September 2005
Formats:txt pdf
Updated by:RFC 4421
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4175
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time TransportProtocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITUBT.601, and standards from the Society of Motion Picture andTelevision Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed.
 
RFC 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files
 
Authors:Y. Shafranovich.
Date:October 2005
Formats:txt pdf
Updated by:RFC 7111
Status:INFORMATIONAL
DOI:10.17487/RFC 4180
This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".
 
RFC 4181 Guidelines for Authors and Reviewers of MIB Documents
 
Authors:C. Heard, Ed..
Date:September 2005
Formats:txt pdf
Updated by:RFC 4841
Also:BCP 0111
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4181
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents.
 
RFC 4182 Removing a Restriction on the use of MPLS Explicit NULL
 
Authors:E. Rosen.
Date:September 2005
Formats:txt pdf
Updates:RFC 3032
Updated by:RFC 5462, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4182
The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of theMPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032.

 
RFC 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
 
Authors:J. Arkko, H. Haverinen.
Date:January 2006
Formats:txt pdf
Updated by:RFC 5448
Status:INFORMATIONAL
DOI:10.17487/RFC 4187
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal MobileTelecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable)User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure.

 
RFC 4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
 
Authors:K. Kompella, Ed., Y. Rekhter, Ed..
Date:October 2005
Formats:txt pdf
Updated by:RFC 6001, RFC 6002, RFC 7074
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4202
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching(GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).
 
RFC 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
 
Authors:K. Kompella, Ed., Y. Rekhter, Ed..
Date:October 2005
Formats:txt pdf
Updates:RFC 3630
Updated by:RFC 6001, RFC 6002, RFC 7074
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4203
This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS).
 
RFC 4204 Link Management Protocol (LMP)
 
Authors:J. Lang, Ed..
Date:October 2005
Formats:txt pdf
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4204
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.
 
RFC 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
 
Authors:K. Kompella, Y. Rekhter.
Date:October 2005
Formats:txt pdf
Updated by:RFC 6001, RFC 6107
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4206
To improve scalability of Generalized Multi-Protocol Label Switching(GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a TrafficEngineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).

This document describes the mechanisms to accomplish this.

 
RFC 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
 
Authors:J. Lang, D. Papadimitriou.
Date:October 2005
Formats:txt pdf
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4207
This document details the Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages.
 
RFC 4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
 
Authors:A. Fredette, Ed., J. Lang, Ed..
Date:October 2005
Formats:txt pdf
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4209
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link InterfaceRequirements" described in a companion document.
 
RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
 
Authors:C. Adams, S. Farrell, T. Kause, T. Mononen.
Date:September 2005
Formats:txt pdf
Obsoletes:RFC 2510
Updated by:RFC 6712
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4210
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system.
 
RFC 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
 
Authors:K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom.
Date:January 2006
Formats:txt pdf
Obsoletes:RFC 3057
Updated by:RFC 5133
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4233
This document defines a protocol for backhauling of IntegratedServices Digital Network (ISDN) Q.921 User messages over IP using theStream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller(MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057.

 
RFC 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg, H. Schulzrinne, R. Mahy, Ed..
Date:November 2005
Formats:txt pdf
Updated by:RFC 7463
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4235
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved.
 
RFC 4238 Voice Message Routing Service
 
Authors:G. Vaudreuil.
Date:October 2005
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4238
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses theVoice Profile for Internet Mail (VPIM) Directory service to lookup aVPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient.However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities.
 
RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers
 
Authors:S. Lehtinen, C. Lonvick, Ed..
Date:January 2006
Formats:txt pdf
Updated by:RFC 8268
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4250
This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents.
 
RFC 4251 The Secure Shell (SSH) Protocol Architecture
 
Authors:T. Ylonen, C. Lonvick, Ed..
Date:January 2006
Formats:txt pdf
Updated by:RFC 8308
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4251
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: TheTransport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. TheUser Authentication Protocol authenticates the client to the server.The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents.
 
RFC 4252 The Secure Shell (SSH) Authentication Protocol
 
Authors:T. Ylonen, C. Lonvick, Ed..
Date:January 2006
Formats:txt pdf
Updated by:RFC 8308, RFC 8332
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4252
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol.
 
RFC 4253 The Secure Shell (SSH) Transport Layer Protocol
 
Authors:T. Ylonen, C. Lonvick, Ed..
Date:January 2006
Formats:txt pdf
Updated by:RFC 6668, RFC 8268, RFC 8308, RFC 8332
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4253
The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.

This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement theSSH transport layer protocol.

 
RFC 4254 The Secure Shell (SSH) Connection Protocol
 
Authors:T. Ylonen, C. Lonvick, Ed..
Date:January 2006
Formats:txt pdf
Updated by:RFC 8308
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4254
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwardedTCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.

The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols.

 
RFC 4271 A Border Gateway Protocol 4 (BGP-4)
 
Authors:Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed..
Date:January 2006
Formats:txt pdf
Obsoletes:RFC 1771
Updated by:RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212
Status:DRAFT STANDARD
DOI:10.17487/RFC 4271
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list ofAutonomous Systems (ASes) that reachability information traverses.This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation ofAS paths.

This document obsoletes RFC 1771.

 
RFC 4287 The Atom Syndication Format
 
Authors:M. Nottingham, Ed., R. Sayre, Ed..
Date:December 2005
Formats:txt pdf
Updated by:RFC 5988
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4287
This document specifies Atom, an XML-based Web content and metadata syndication format.
 
RFC 4291 IP Version 6 Addressing Architecture
 
Authors:R. Hinden, S. Deering.
Date:February 2006
Formats:txt pdf
Obsoletes:RFC 3513
Updated by:RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064
Status:DRAFT STANDARD
DOI:10.17487/RFC 4291
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 AddressingArchitecture".

 
RFC 4294 IPv6 Node Requirements
 
Authors:J. Loughney, Ed..
Date:April 2006
Formats:txt pdf
Obsoleted by:RFC 6434
Updated by:RFC 5095
Status:INFORMATIONAL
DOI:10.17487/RFC 4294
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
 
RFC 4301 Security Architecture for the Internet Protocol
 
Authors:S. Kent, K. Seo.
Date:December 2005
Formats:txt pdf
Obsoletes:RFC 2401
Updates:RFC 3168
Updated by:RFC 6040, RFC 7619
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4301
This document describes an updated version of the "SecurityArchitecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401(November 1998).
 
RFC 4306 Internet Key Exchange (IKEv2) Protocol
 
Authors:C. Kaufman, Ed..
Date:December 2005
Formats:txt pdf
Obsoletes:RFC 2407, RFC 2408, RFC 2409
Obsoleted by:RFC 5996
Updated by:RFC 5282
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4306
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 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
 
Authors:G. Fairhurst, B. Collini-Nocker.
Date:December 2005
Formats:txt pdf
Updated by:RFC 7280
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4326
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

This document describes a Unidirectional Lightweight Encapsulation(ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 TransportStream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.

 
RFC 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
 
Authors:D. Papadimitriou, Ed..
Date:January 2006
Formats:txt pdf
Updates:RFC 3471
Updated by:RFC 7139
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4328
This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to controlOptical Transport Networks (OTN); it also includes the so-called pre-OTN developments.
 
RFC 4337 MIME Type Registration for MPEG-4
 
Authors:Y Lim, D. Singer.
Date:March 2006
Formats:txt pdf
Updated by:RFC 6381
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4337
This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents.
 
RFC 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
 
Authors:C. DeSanti, C. Carlson, R. Nixon.
Date:January 2006
Formats:txt pdf
Obsoletes:RFC 3831, RFC 2625
Updated by:RFC 5494, RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4338
This document specifies the way of encapsulating IPv6, IPv4, andAddress Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on FibreChannel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.

This document obsoletes RFC 2625 and RFC 3831.

 
RFC 4340 Datagram Congestion Control Protocol (DCCP)
 
Authors:E. Kohler, M. Handley, S. Floyd.
Date:March 2006
Formats:txt pdf
Updated by:RFC 5595, RFC 5596, RFC 6335, RFC 6773
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4340
The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
 
RFC 4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
 
Authors:S. Floyd, E. Kohler.
Date:March 2006
Formats:txt pdf
Updated by:RFC 8311
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4341
This document contains the profile for Congestion Control Identifier2 (CCID 2), TCP-like Congestion Control, in the Datagram CongestionControl Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's AdditiveIncrease Multiplicative Decrease (AIMD) congestion control.
 
RFC 4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
 
Authors:S. Floyd, E. Kohler, J. Padhye.
Date:March 2006
Formats:txt pdf
Updated by:RFC 5348, RFC 6323, RFC 8311
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4342
This document contains the profile for Congestion Control Identifier3, TCP-Friendly Rate Control (TFRC), in the Datagram CongestionControl Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit CongestionNotification (ECN), while minimizing abrupt rate changes.
 
RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1
 
Authors:T. Dierks, E. Rescorla.
Date:April 2006
Formats:txt pdf
Obsoletes:RFC 2246
Obsoleted by:RFC 5246
Updated by:RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4346
This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
 
RFC 4347 Datagram Transport Layer Security
 
Authors:E. Rescorla, N. Modadugu.
Date:April 2006
Formats:txt pdf
Obsoleted by:RFC 6347
Updated by:RFC 5746, RFC 7507
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4347
This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
 
RFC 4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
 
Authors:S. Ahmadi.
Date:January 2006
Formats:txt pdf
Updated by:RFC 4424
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4348
This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.

VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB(i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved.

 
RFC 4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
 
Authors:C. Pignataro, M. Townsley.
Date:February 2006
Formats:txt pdf
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4349
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelHigh-Level Data Link Control (HDLC) frames over L2TPv3.
 
RFC 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms
 
Authors:R. Brandner, L. Conroy, R. Stastny.
Date:January 2006
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4355
This document registers the Enumservices "email", "fax", "sms","ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761.
 
RFC 4360 BGP Extended Communities Attribute
 
Authors:S. Sangli, D. Tappan, Y. Rekhter.
Date:February 2006
Formats:txt pdf
Updated by:RFC 7153, RFC 7606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4360
This document describes the "extended community" BGP-4 attribute.This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications.
 
RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
 
Authors:T. Lemon, B. Sommerfeld.
Date:February 2006
Formats:txt pdf
Updates:RFC 2131, RFC 2132, RFC 3315
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4361
This document specifies the format that is to be used for encodingDynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers.
 
RFC 4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
 
Authors:L-E. Jonsson, G. Pelletier, K. Sandlund.
Date:January 2006
Formats:txt pdf
Obsoletes:RFC 3242
Updated by:RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4362
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format.This document is a replacement for RFC 3242, which it obsoletes.
 
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)
 
Authors:E. Rosen, Y. Rekhter.
Date:February 2006
Formats:txt pdf
Obsoletes:RFC 2547
Updated by:RFC 4577, RFC 4684, RFC 5462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4364
This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.

This document obsoletes RFC 2547.

 
RFC 4366 Transport Layer Security (TLS) Extensions
 
Authors:S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright.
Date:April 2006
Formats:txt pdf
Obsoletes:RFC 3546
Obsoleted by:RFC 5246, RFC 6066
Updates:RFC 4346
Updated by:RFC 5746
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4366
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa.

 
RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
 
Authors:K. Kompella, G. Swallow.
Date:February 2006
Formats:txt pdf
Obsoleted by:RFC 8029
Updates:RFC 1122
Updated by:RFC 5462, RFC 6424, RFC 6425, RFC 6426, RFC 6829, RFC 7506, RFC 7537, RFC 7743
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4379
This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching(MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply.
 
RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
 
Authors:C. Huitema.
Date:February 2006
Formats:txt pdf
Updated by:RFC 5991, RFC 6081
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4380
We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; theTeredo relays act as IPv6 routers between the Teredo service and the"native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".
 
RFC 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
 
Authors:S. Bryant, G. Swallow, L. Martini, D. McPherson.
Date:February 2006
Formats:txt pdf
Updated by:RFC 5586
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4385
This document describes the preferred design of a PseudowireEmulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated ChannelHeader. The design of these fields is chosen so that an MPLS LabelSwitching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.
 
RFC 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery
 
Authors:R. Woundy, K. Kinnear.
Date:February 2006
Formats:txt pdf
Updated by:RFC 6148
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4388
A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided toDHCPv4 clients. Other processes and devices that already make use ofDHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.
 
RFC 4391 Transmission of IP over InfiniBand (IPoIB)
 
Authors:J. Chu, V. Kashyap.
Date:April 2006
Formats:txt pdf
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4391
This document specifies a method for encapsulating and transmittingIPv4/IPv6 and Address Resolution Protocol (ARP) packets overInfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets.The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links.
 
RFC 4393 MIME Type Registrations for 3GPP2 Multimedia Files
 
Authors:H. Garudadri.
Date:March 2006
Formats:txt pdf
Updated by:RFC 6381
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4393
This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format.
 
RFC 4398 Storing Certificates in the Domain Name System (DNS)
 
Authors:S. Josefsson.
Date:March 2006
Formats:txt pdf
Obsoletes:RFC 2538
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4398
Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).

This document obsoletes RFC 2538.

 
RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
 
Authors:M. Wong, W. Schlitt.
Date:April 2006
Formats:txt pdf
Obsoleted by:RFC 7208
Updated by:RFC 6652
Status:EXPERIMENTAL
DOI:10.17487/RFC 4408
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.
 
RFC 4412 Communications Resource Priority for the Session Initiation Protocol (SIP)
 
Authors:H. Schulzrinne, J. Polk.
Date:February 2006
Formats:txt pdf
Updated by:RFC 7134
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4412
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely,"Resource-Priority" and "Accept-Resource-Priority". The"Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior ofIP routers.
 
RFC 4415 IANA Registration for Enumservice Voice
 
Authors:R. Brandner, L. Conroy, R. Stastny.
Date:February 2006
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4415
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in theENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.
 
RFC 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
 
Authors:M. Friedl, N. Provos, W. Simpson.
Date:March 2006
Formats:txt pdf
Updated by:RFC 8270
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4419
This memo describes a new key exchange method for the Secure Shell(SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.
 
RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
 
Authors:N. Moore.
Date:April 2006
Formats:txt pdf
Updated by:RFC 7527
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4429
Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) andStateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers.
 
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
 
Authors:A. Conta, S. Deering, M. Gupta, Ed..
Date:March 2006
Formats:txt pdf
Obsoletes:RFC 2463
Updates:RFC 2780
Updated by:RFC 4884
Also:STD 0089
Status:INTERNET STANDARD
DOI:10.17487/RFC 4443
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is theInternet Control Message Protocol for Internet Protocol version 6(IPv6).
 
RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
 
Authors:L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron.
Date:April 2006
Formats:txt pdf
Obsoleted by:RFC 8077
Updated by:RFC 6723, RFC 6870, RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4447
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents.
 
RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks
 
Authors:L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron.
Date:April 2006
Formats:txt pdf
Updated by:RFC 5462, RFC 8469
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4448
An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 ProtocolData Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation ofEthernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service.
 
RFC 4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
 
Authors:S. Singh, M. Townsley, C. Pignataro.
Date:May 2006
Formats:txt pdf
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4454
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use theL2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over anIP network.
 
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
 
Authors:T. Bates, E. Chen, R. Chandra.
Date:April 2006
Formats:txt pdf
Obsoletes:RFC 2796, RFC 1966
Updated by:RFC 7606
Status:DRAFT STANDARD
DOI:10.17487/RFC 4456
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as"route reflection" to alleviate the need for "full mesh" Internal BGP(IBGP).

This document obsoletes RFC 2796 and RFC 1966.

 
RFC 4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
 
Authors:C. Jennings, F. Audet, J. Elwell.
Date:April 2006
Formats:txt pdf
Updated by:RFC 8119
Status:INFORMATIONAL
DOI:10.17487/RFC 4458
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
 
RFC 4466 Collected Extensions to IMAP4 ABNF
 
Authors:A. Melnikov, C. Daboo.
Date:April 2006
Formats:txt pdf
Updates:RFC 2088, RFC 2342, RFC 3501, RFC 3502, RFC 3516
Updated by:RFC 6237, RFC 7377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4466
Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.

This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined inRFC 3501. The patterns provide for compatibility between existing and future extensions.

This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.

 
RFC 4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension
 
Authors:M. Crispin.
Date:May 2006
Formats:txt pdf
Updated by:RFC 5092, RFC 5550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4467
This document describes the URLAUTH extension to the Internet MessageAccess Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)(RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.

An IMAP server that supports this extension indicates this with a capability name of "URLAUTH".

 
RFC 4468 Message Submission BURL Extension
 
Authors:C. Newman.
Date:May 2006
Formats:txt pdf
Updates:RFC 3463
Updated by:RFC 5248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4468
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server.
 
RFC 4469 Internet Message Access Protocol (IMAP) CATENATE Extension
 
Authors:P. Resnick.
Date:April 2006
Formats:txt pdf
Updates:RFC 3501, RFC 3502
Updated by:RFC 5550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4469
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on theIMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
 
RFC 4486 Subcodes for BGP Cease Notification Message
 
Authors:E. Chen, V. Gillet.
Date:April 2006
Formats:txt pdf
Updated by:RFC 8203
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4486
This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues.
 
RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
 
Authors:S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller.
Date:May 2006
Formats:txt pdf
Obsoleted by:RFC 8422
Updated by:RFC 5246, RFC 7027, RFC 7919
Status:INFORMATIONAL
DOI:10.17487/RFC 4492
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 4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
 
Authors:O. Levin, A. Johnston.
Date:May 2006
Formats:txt pdf
Updated by:RFC 8217
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4508
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach.
 
RFC 4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
 
Authors:F. Baker, J. Polk.
Date:May 2006
Formats:txt pdf
Updated by:RFC 5865
Status:INFORMATIONAL
DOI:10.17487/RFC 4542
RFCs 3689 and 3690 detail requirements for an EmergencyTelecommunications Service (ETS), of which an Internet EmergencyPreparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-LevelPrecedence and Preemption (MLPP) and Government EmergencyTelecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations.

 
RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
 
Authors:L. Zhu, B. Tung.
Date:June 2006
Formats:txt pdf
Updated by:RFC 6112, RFC 8062
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4556
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields.
 
RFC 4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
 
Authors:E. Carrara, V. Lehtovirta, K. Norrman.
Date:June 2006
Formats:txt pdf
Updated by:RFC 6309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4563
This memo specifies a new Type (the Key ID Information Type) for theGeneral Extension Payload in the Multimedia Internet KEYing (MIKEY)Protocol. This is used in, for example, the MultimediaBroadcast/Multicast Service specified in the Third GenerationPartnership Project.
 
RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
 
Authors:J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey.
Date:July 2006
Formats:txt pdf
Updated by: