Internet Documents

RFCs

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

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 10 Documentation conventions
 
Authors:S.D. Crocker.
Date:July 1969
Formats:txt json html
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 html json
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 json html
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 html json
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 html json
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 html json
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 json html
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 html json
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 json html
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 html json
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 html json 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 html json
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 json html
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 html json
Updated by:RFC 0123
Status:UNKNOWN
DOI:10.17487/RFC 0098
 
 
RFC 99 Network Meeting
 
Authors:P.M. Karp.
Date:February 1971
Formats:txt html json
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 json html
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 html json
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 json html
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 html json
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 json html
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 json html
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 html json
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 json html
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 html json
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 html json
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 html json
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 json html
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 html json
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 json html
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 html json
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 json html
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 html json
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 html ps pdf json
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 html pdf json
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 html json
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 html json
Obsoleted by:RFC 0264
Updates:RFC 0114
Updated by:RFC 0238
Status:UNKNOWN
DOI:10.17487/RFC 0171
 
 
RFC 172 The File Transfer Protocol
 
Authors:A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White.
Date:June 1971
Formats:txt json html
Obsoleted by:RFC 0265
Updates:RFC 0114
Updated by:RFC 0238
Status:UNKNOWN
DOI:10.17487/RFC 0172
 
 
RFC 177 Device independent graphical display description
 
Authors:J. McConnell.
Date:June 1971
Formats:txt json html
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 html json
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 json html
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 html json
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 json html
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 json html
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 json html
Obsoletes:RFC 0171
Obsoleted by:RFC 0354
Updated by:RFC 0310
Also:RFC 0265
Status:UNKNOWN
DOI:10.17487/RFC 0264
 
 
RFC 265 The File Transfer Protocol
 
Authors:A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White.
Date:November 1971
Formats:txt json html
Obsoletes:RFC 0172
Obsoleted by:RFC 0354
Updated by:RFC 0281, RFC 0294, RFC 0310
Also:RFC 0264
Status:UNKNOWN
DOI:10.17487/RFC 0265
 
 
RFC 288 Network host status
 
Authors:E. Westheimer.
Date:January 1972
Formats:txt json html
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 json html
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 json html
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 html json
Updated by:RFC 0388
Status:UNKNOWN
DOI:10.17487/RFC 0323
 
 
RFC 330 Network Host Status
 
Authors:E. Westheimer.
Date:April 1972
Formats:txt json html
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 html json
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 html json
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 html json
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 html json
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 json html
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 json html
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 html json
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 html json
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 html json
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 html json
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 json html
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 json html
Updated by:RFC 0556
Status:UNKNOWN
DOI:10.17487/RFC 0538
 
 
RFC 542 File Transfer Protocol
 
Authors:N. Neigus.
Date:August 1973
Formats:txt json html
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 html json
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 html json
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 json html
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 json html
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 html pdf json
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 html json
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 json html
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 json html
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 json html
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 json pdf html
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 json pdf html
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 json pdf html
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 html json
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 json html
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 json html
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 html json
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 html json
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 html json
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 html json
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 json html
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 json html
Obsoletes:RFC 0761
Obsoleted by:RFC 9293
Updated by:RFC 1122, RFC 3168, RFC 6093, RFC 6528
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 html json
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 html json
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 html json
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 json html
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 html json
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 html json
Obsoleted by:RFC 7805, RFC 9293
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 html json
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. Mockapetris.
Date:November 1983
Formats:txt json html
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. Mockapetris.
Date:November 1983
Formats:txt json html
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 html json
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 json html
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 and Newman Laboratories.
Date:July 1984
Formats:txt json html
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 html json
Updated by:RFC 1151
Status:EXPERIMENTAL
DOI:10.17487/RFC 0908
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
 
RFC 950 Internet Standard Subnetting Procedure
 
Authors:J.C. Mogul, J. Postel.
Date:August 1985
Formats:txt json html
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 json html
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 html json
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 json html
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 html json
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 html json
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 json html
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 json html
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 html json
Obsoletes:RFC 0991
Updated by:RFC 6093, RFC 9293
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 json html
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. Mockapetris.
Date:November 1987
Formats:txt html json
Obsoletes:RFC 0973, RFC 0882, RFC 0883
Updated by:RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 4035, RFC 4592, RFC 5936, RFC 8020, RFC 8482, RFC 8767, RFC 9471
Also:STD 0013
Status:INTERNET STANDARD
DOI:10.17487/RFC 1034
This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.
 
RFC 1035 Domain names - implementation and specification
 
Authors:P. Mockapetris.
Date:November 1987
Formats:txt html json
Obsoletes:RFC 0973, RFC 0882, RFC 0883
Updated by:RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766, RFC 8482, RFC 8490, RFC 8767
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 json html
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 json html
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 json html
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 json html
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 json html
Updated by:RFC 1141
Status:INFORMATIONAL
DOI:10.17487/RFC 1071
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.
 
RFC 1112 Host extensions for IP multicasting
 
Authors:S.E. Deering.
Date:August 1989
Formats:txt html json
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 html json
Updates:RFC 0793
Updated by:RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293
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 html json
Updates:RFC 0822, RFC 0952
Updated by:RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766, RFC 9210
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 json html
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 html json
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 html json
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 json html
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. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris, Ed..
Date:October 1990
Formats:txt json html
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. Callon.
Date:December 1990
Formats:txt html ps json 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 html json
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 json html
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 html json
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 html json
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 html json
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 json html
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 json html
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 html json
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 html pdf json 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 json html
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 json html
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 json html
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 json html
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 html json
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 json html
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 html json
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 html json
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 html json
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 html json
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 json html
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 json html
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 1536 Common DNS Implementation Errors and Suggested Fixes
 
Authors:A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller.
Date:October 1993
Formats:txt html json
Updated by:RFC 9210
Status:INFORMATIONAL
DOI:10.17487/RFC 1536
This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND(versions 4.8.3 and 4.9 which the authors referred to) to serve as an example.
 
RFC 1548 The Point-to-Point Protocol (PPP)
 
Authors:W. Simpson.
Date:December 1993
Formats:txt html json
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 html json
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 json html
Obsoletes:RFC 1310
Obsoleted by:RFC 2026
Updated by:RFC 1871
Status:INFORMATIONAL
DOI:10.17487/RFC 1602
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.

This revision (revision 2) includes the following major changes:

(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.

(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).

(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.

(d) An appeals procedure is added (Section 3.6).

(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.

(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C.

 
RFC 1603 IETF Working Group Guidelines and Procedures
 
Authors:E. Huizer, D. Crocker.
Date:March 1994
Formats:txt json html
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 json html
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 1706 DNS NSAP Resource Records
 
Authors:B. Manning, R. Colella.
Date:October 1994
Formats:txt html json
Obsoletes:RFC 1637
Updated by:RFC 9121
Status:HISTORIC
DOI:10.17487/RFC 1706
OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet. Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System(DNS) for mapping between names and NSAP addresses.

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format.

NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.

This document obsoletes RFC 1348 and RFC 1637.

 
RFC 1715 The H Ratio for Address Assignment Efficiency
 
Authors:C. Huitema.
Date:November 1994
Formats:txt json html
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 json html
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 html json
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 html json
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 json html
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 json html
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 html json
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 html json
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 json html
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 html json
Updated by:RFC 3128
Status:INFORMATIONAL
DOI:10.17487/RFC 1858
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them.
 
RFC 1886 DNS Extensions to support IP version 6
 
Authors:S. Thomson, C. Huitema.
Date:December 1995
Formats:txt json html
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 html json
Obsoleted by:RFC 4048
Updated by:RFC 4548
Status:HISTORIC
DOI:10.17487/RFC 1888
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.
 
RFC 1894 An Extensible Message Format for Delivery Status Notifications
 
Authors:K. Moore, G. Vaudreuil.
Date:January 1996
Formats:txt html json
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 html json
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 html json
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 html json
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 json html
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 html json
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 json html
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 html json
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 html json
Updated by:RFC 2297
Status:INFORMATIONAL
DOI:10.17487/RFC 1987
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.
 
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
 
Authors:W. Simpson.
Date:August 1996
Formats:txt json html
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 1995 Incremental Zone Transfer in DNS
 
Authors:M. Ohta.
Date:August 1996
Formats:txt json html
Updates:RFC 1035
Updated by:RFC 9103
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1995
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
 
RFC 1997 BGP Communities Attribute
 
Authors:R. Chandra, P. Traina, T. Li.
Date:August 1996
Formats:txt html json
Updated by:RFC 7606, RFC 8642
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 html json
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 html json
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 json html
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 html json
Obsoletes:RFC 1602, RFC 1871
Updated by:RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282
Also:BCP 0009
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2026
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
 
RFC 2028 The Organizations Involved in the IETF Standards Process
 
Authors:R. Hovey, S. Bradner.
Date:October 1996
Formats:txt json html
Obsoleted by:RFC 9281
Updated by:RFC 3668, RFC 3979, RFC 8717
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 html json
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 json html
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 json html
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 html json
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 json html
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 2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions
 
Authors:S. Nelson, C. Parks, Mitra.
Date:January 1997
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2077
The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK]
 
RFC 2088 IMAP4 non-synchronizing literals
 
Authors:J. Myers.
Date:January 1997
Formats:txt html json
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 html json
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 2104
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function.
 
RFC 2113 IP Router Alert Option
 
Authors:D. Katz.
Date:February 1997
Formats:txt json html
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 html json
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 html json
Updated by:RFC 6055
Status:INFORMATIONAL
DOI:10.17487/RFC 2130
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols.
 
RFC 2131 Dynamic Host Configuration Protocol
 
Authors:R. Droms.
Date:March 1997
Formats:txt html json
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 json html
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 json html
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 html json
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 html json
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 json html
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 json html
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 html json
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 json html
Updates:RFC 1034, RFC 1035, RFC 1123
Updated by:RFC 4035, RFC 2535, RFC 4343, RFC 4033, RFC 4034, RFC 5452, RFC 8767
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 html json
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 json html
Updated by:RFC 6354
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2198
This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications.
 
RFC 2203 RPCSEC_GSS Protocol Specification
 
Authors:M. Eisler, A. Chiu, L. Ling.
Date:September 1997
Formats:txt html json
Updated by:RFC 5403
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2203
This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services ApplicationProgramming Interface (referred to henceforth as GSS-API).
 
RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
 
Authors:R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin.
Date:September 1997
Formats:txt json html
Updated by:RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2205
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
 
RFC 2222 Simple Authentication and Security Layer (SASL)
 
Authors:J. Myers.
Date:October 1997
Formats:txt html json
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 html json
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 json html
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 html json
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 html json
Updated by:RFC 6075
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2244
The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.
 
RFC 2246 The TLS Protocol Version 1.0
 
Authors:T. Dierks, C. Allen.
Date:January 1999
Formats:txt json html
Obsoleted by:RFC 4346
Updated by:RFC 3546, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Status:HISTORIC
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 json html
Updated by:RFC 4519, RFC 4524
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2247
This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]
 
RFC 2251 Lightweight Directory Access Protocol (v3)
 
Authors:M. Wahl, T. Howes, S. Kille.
Date:December 1997
Formats:txt html json
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 json html
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 json html
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 html json
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 html json
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 json html
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 json html
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 html json
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 html json
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 html json
Updates:RFC 1034, RFC 1035
Updated by:RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020, RFC 8499, RFC 9499, RFC 9520
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 html json
Obsoleted by:RFC 7567
Updated by:RFC 7141
Status:INFORMATIONAL
DOI:10.17487/RFC 2309
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
 
RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
 
Authors:L. Masinter.
Date:1 April 1998
Formats:txt html json
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 json html
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 html json
Obsoletes:RFC 2178
Updated by:RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454
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 html json
Updated by:RFC 7312, RFC 8468, RFC 9198
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 html json
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 json html
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 json html
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 html json
Updated by:RFC 4519
Status:INFORMATIONAL
DOI:10.17487/RFC 2377
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach.
 
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
 
Authors:A. Heffernan.
Date:August 1998
Formats:txt json html
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 html json
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 json html
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 json html
Obsoleted by:RFC 4306
Updated by:RFC 4109
Status:HISTORIC
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 json html
Obsoletes:RFC 1603
Updated by:RFC 3934, RFC 7475, RFC 7776, RFC 8717, RFC 9141
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 json html
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 html json
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 json html
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 html json
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 html json
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 html json
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 json html
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 html json
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2470
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]
 
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
 
Authors:K. Nichols, S. Blake, F. Baker, D. Black.
Date:December 1998
Formats:txt html json
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 html json
Updated by:RFC 3260
Status:INFORMATIONAL
DOI:10.17487/RFC 2475
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field[DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.
 
RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks
 
Authors:G. Armitage, P. Schulter, M. Jork, G. Harter.
Date:January 1999
Formats:txt html json
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2491
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.

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

 
RFC 2492 IPv6 over ATM Networks
 
Authors:G. Armitage, P. Schulter, M. Jork.
Date:January 1999
Formats:txt json html
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2492
This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths(when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.
 
RFC 2497 Transmission of IPv6 Packets over ARCnet Networks
 
Authors:I. Souvatzis.
Date:January 1999
Formats:txt json html
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 json html
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 html json
Obsoletes:RFC 2065
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 2181, RFC 1035, RFC 1034
Updated by:RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2535
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.

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

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

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

 
RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt json html
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 html json
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 json html
Obsoletes:RFC 1944
Updated by:RFC 6201, RFC 6815, RFC 9004
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 html json
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 2555 30 Years of RFCs
 
Authors:RFC Editor, et al..
Date:April 1999
Formats:txt json html
Updated by:RFC 8700
Status:INFORMATIONAL
DOI:10.17487/RFC 2555
The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.
 
RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
 
Authors:M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
Date:June 1999
Formats:txt json html
Obsoleted by:RFC 6960
Updated by:RFC 6277
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2560
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK]
 
RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
 
Authors:R. Troll.
Date:May 1999
Formats:txt html json
Updated by:RFC 8925
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2563
Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum.To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-localIP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own.
 
RFC 2581 TCP Congestion Control
 
Authors:M. Allman, V. Paxson, W. Stevens.
Date:April 1999
Formats:txt json html
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 json html
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2590
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
 
RFC 2595 Using TLS with IMAP, POP3 and ACAP
 
Authors:C. Newman.
Date:June 1999
Formats:txt json html
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 html json
Updated by:RFC 3260
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2597
This document defines a general use Differentiated Services (DS)[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.
 
RFC 2606 Reserved Top Level DNS Names
 
Authors:D. Eastlake 3rd, A. Panitz.
Date:June 1999
Formats:txt html json
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 json html
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 html pdf json
Obsoletes:RFC 2068
Obsoleted by:RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Updated by:RFC 2817, RFC 5785, RFC 6266, RFC 6585
Status:DRAFT STANDARD
DOI:10.17487/RFC 2616
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

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

 
RFC 2622 Routing Policy Specification Language (RPSL)
 
Authors:C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra.
Date:June 1999
Formats:txt html json
Obsoletes:RFC 2280
Updated by:RFC 4012, RFC 7909
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2622
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
 
RFC 2634 Enhanced Security Services for S/MIME
 
Authors:P. Hoffman, Ed..
Date:June 1999
Formats:txt json html
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 html json
Updated by:RFC 6924, RFC 9141
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 json html
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 json html
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 json html
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 html json
Obsoleted by:RFC 3435
Updated by:RFC 3660
Status:INFORMATIONAL
DOI:10.17487/RFC 2705
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.

The document is structured in 6 main sections:

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

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

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

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

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

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

 
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
 
Authors:S. Deering, W. Fenner, B. Haberman.
Date:October 1999
Formats:txt html json
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 html json
Updated by:RFC 6398
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2711
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
 
RFC 2725 Routing Policy System Security
 
Authors:C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy.
Date:December 1999
Formats:txt html json
Updated by:RFC 4012
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2725
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
 
RFC 2736 Guidelines for Writers of RTP Payload Format Specifications
 
Authors:M. Handley, C. Perkins.
Date:December 1999
Formats:txt json html
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 html json
Updated by:RFC 6350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2739
When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event.

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

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

- Manual transfer of the information;

- Personal data exchange using the vCard format; and

- Directory lookup using the LDAP protocol.

 
RFC 2743 Generic Security Service Application Program Interface Version 2, Update 1
 
Authors:J. Linn.
Date:January 2000
Formats:txt html json
Obsoletes:RFC 2078
Updated by:RFC 5554, RFC 5896
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 2744 Generic Security Service API Version 2 : C-bindings
 
Authors:J. Wray.
Date:January 2000
Formats:txt json html
Obsoletes:RFC 1509
Updated by:RFC 5896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2744
This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC-2743 [GSSAPI]. It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track.

The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.

 
RFC 2747 RSVP Cryptographic Authentication
 
Authors:F. Baker, B. Lindell, M. Talwar.
Date:January 2000
Formats:txt html json
Updated by:RFC 3097
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2747
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
 
RFC 2748 The COPS (Common Open Policy Service) Protocol
 
Authors:D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry.
Date:January 2000
Formats:txt json html
Updated by:RFC 4261
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2748
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
 
RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
 
Authors:G. Tsirtsis, P. Srisuresh.
Date:February 2000
Formats:txt html json
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 html json
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 json html
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 html json
Obsoletes:RFC 2052
Updated by:RFC 6335, RFC 8553
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 json html
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 json html
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 json html
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 html json
Obsoleted by:RFC 9110
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 html json
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 json html
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 json html
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 html json
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 html json
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 json html
Updated by:RFC 3632
Status:INFORMATIONAL
DOI:10.17487/RFC 2832
This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry.

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

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

 
RFC 2834 ARP and IP Broadcast over HIPPI-800
 
Authors:J.-M. Pittet.
Date:May 2000
Formats:txt html json
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 html json
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 json html
Obsoleted by:RFC 8945
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 html json
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 2850 Charter of the Internet Architecture Board (IAB)
 
Authors:Internet Architecture Board, B. Carpenter, Ed..
Date:May 2000
Formats:txt json html
Obsoletes:RFC 1601
Updated by:RFC 9283
Also:BCP 0039
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2850
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC1601.
 
RFC 2863 The Interfaces Group MIB
 
Authors:K. McCloghrie, F. Kastenholz.
Date:June 2000
Formats:txt html json
Obsoletes:RFC 2233
Updated by:RFC 8892
Status:DRAFT STANDARD
DOI:10.17487/RFC 2863
This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS TRACK]
 
RFC 2865 Remote Authentication Dial In User Service (RADIUS)
 
Authors:C. Rigney, S. Willens, A. Rubens, W. Simpson.
Date:June 2000
Formats:txt json html
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 html json
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 json html
Updates:RFC 2865
Updated by:RFC 3575
Status:INFORMATIONAL
DOI:10.17487/RFC 2868
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
 
RFC 2869 RADIUS Extensions
 
Authors:C. Rigney, W. Willats, P. Calhoun.
Date:June 2000
Formats:txt json html
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 json html
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 json html
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 json html
Obsoletes:RFC 2565
Obsoleted by:RFC 8010
Updated by:RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2910
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext TransferProtocol (HTTP) a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.

The full set of IPP documents includes:

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

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

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

The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.

The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.

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

 
RFC 2911 Internet Printing Protocol/1.1: Model and Semantics
 
Authors:T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell.
Date:September 2000
Formats:txt json html
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 json html
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 json html
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 json html
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 2954 Definitions of Managed Objects for Frame Relay Service
 
Authors:K. Rehbehn, D. Fowler.
Date:October 2000
Formats:txt html json
Obsoletes:RFC 1604
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2954
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TransmissionControl Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service.

This document obsoletes RFC 1604.

 
RFC 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
 
Authors:K. Rehbehn, O. Nicklass, G. Mouradian.
Date:October 2000
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2955
This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) forPermanent Virtual Connections (PVC) between Frame Relay andAsynchronous Transfer Mode (ATM) technologies.
 
RFC 2960 Stream Control Transmission Protocol
 
Authors:R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson.
Date:October 2000
Formats:txt html json
Obsoleted by:RFC 4960
Updated by:RFC 3309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2960
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.

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

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

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

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

 
RFC 2961 RSVP Refresh Overhead Reduction Extensions
 
Authors:L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini.
Date:April 2001
Formats:txt html json
Updated by:RFC 5063
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2961
This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP(Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages.The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.
 
RFC 2980 Common NNTP Extensions
 
Authors:S. Barber.
Date:October 2000
Formats:txt html json
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 json html
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 3005 IETF Discussion List Charter
 
Authors:S. Harris.
Date:November 2000
Formats:txt json html
Obsoleted by:RFC 9245
Updated by:RFC 8717
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3005
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed.Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature.
 
RFC 3008 Domain Name System Security (DNSSEC) Signing Authority
 
Authors:B. Wellington.
Date:November 2000
Formats:txt json html
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 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
 
Authors:P. Pate, B. Lynch, K. Rehbehn.
Date:December 2000
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3020
This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information.
 
RFC 3023 XML Media Types
 
Authors:M. Murata, S. St. Laurent, D. Kohn.
Date:January 2001
Formats:txt html json
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 json html
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 html json
Updated by:RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3032
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.
 
RFC 3038 VCID Notification over ATM link for LDP
 
Authors:K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan.
Date:January 2001
Formats:txt json html
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3038
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
 
RFC 3046 DHCP Relay Agent Information Option
 
Authors:M. Patrick.
Date:January 2001
Formats:txt json html
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 json html
Obsoleted by:RFC 4233
Updated by:RFC 3807
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3057
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
 
RFC 3060 Policy Core Information Model -- Version 1 Specification
 
Authors:B. Moore, E. Ellesson, J. Strassner, A. Westerinen.
Date:February 2001
Formats:txt html json
Updated by:RFC 3460
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3060
This document presents the object-oriented information model for representing policy information developed jointly in the IETF PolicyFramework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol.
 
RFC 3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems
 
Authors:R. Woundy.
Date:March 2001
Formats:txt json html
Updated by:RFC 9141
Status:INFORMATIONAL
DOI:10.17487/RFC 3083
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the BaselinePrivacy Interface (BPI), which provides data privacy for DOCSIS 1.0(Data-Over-Cable Service Interface Specifications) compliant CableModems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.

This memo specifies a MIB module in a manner that is compliant to theSMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards.

CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification.

 
RFC 3090 DNS Security Extension Clarification on Zone Status
 
Authors:E. Lewis.
Date:March 2001
Formats:txt html json
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 html json
Updated by:RFC 3759, RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3095
This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol), UDP/IP, and ESP/IP(Encapsulating Security Payload) headers.

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

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

 
RFC 3106 ECML v1.1: Field Specifications for E-Commerce
 
Authors:D. Eastlake 3rd, T. Goldstein.
Date:April 2001
Formats:txt json html
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 json html
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 html json
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 html json
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3146
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
 
RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
 
Authors:C. Adams, P. Cain, D. Pinkas, R. Zuccherato.
Date:August 2001
Formats:txt json html
Updated by:RFC 5816
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3161
This document describes the format of a request sent to a TimeStamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses.
 
RFC 3162 RADIUS and IPv6
 
Authors:B. Aboba, G. Zorn, D. Mitton.
Date:August 2001
Formats:txt html json
Updated by:RFC 8044
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3162
This document specifies the operation of RADIUS (RemoteAuthentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access.
 
RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP
 
Authors:K. Ramakrishnan, S. Floyd, D. Black.
Date:September 2001
Formats:txt json html
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 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")
 
Authors:G. Huston, Ed..
Date:September 2001
Formats:txt html json
Updated by:RFC 9120
Also:BCP 0052
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3172
This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. The "arpa" domain is used to support a class of infrastructural identifier spaces, providing a distributed database that translates elements of a structured name space derived from a protocol family to service names. The efficient and reliable operation of this DNS space is essential to the integrity of operation of various services within the Internet. The Internet Architecture Board (IAB) has the responsibility, in cooperation with the Internet Corporation forAssigned Names and Numbers (ICANN), to manage the "arpa" domain.This document describes the principles used by the IAB in undertaking this role.
 
RFC 3174 US Secure Hash Algorithm 1 (SHA1)
 
Authors:D. Eastlake 3rd, P. Jones.
Date:September 2001
Formats:txt json html
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 json html
Updated by:RFC 5350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3175
This document describes the use of a single RSVP (ResourceReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM(Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.
 
RFC 3201 Definitions of Managed Objects for Circuit to Interface Translation
 
Authors:R. Steinberger, O. Nicklass.
Date:January 2002
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3201
This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existingMIB modules.
 
RFC 3202 Definitions of Managed Objects for Frame Relay Service Level Definitions
 
Authors:R. Steinberger, O. Nicklass.
Date:January 2002
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3202
This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service Level Definitions.
 
RFC 3203 DHCP reconfigure extension
 
Authors:Y. T'Joens, C. Hublet, P. De Schrijver.
Date:December 2001
Formats:txt html json
Updated by:RFC 6704
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3203
This document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described.
 
RFC 3204 MIME media types for ISUP and QSIG Objects
 
Authors:E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun.
Date:December 2001
Formats:txt json html
Updated by:RFC 3459, RFC 5621
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3204
This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identifyISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN.
 
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security
 
Authors:P. Hoffman.
Date:February 2002
Formats:txt html json
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 json html
Updated by:RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3209
This document describes the use of RSVP (Resource ReservationProtocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.

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

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

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

 
RFC 3219 Telephony Routing over IP (TRIP)
 
Authors:J. Rosenberg, H. Salama, M. Squire.
Date:January 2002
Formats:txt json html
Updated by:RFC 8602
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3219
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations.TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol.

The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

 
RFC 3225 Indicating Resolver Support of DNSSEC
 
Authors:D. Conrad.
Date:December 2001
Formats:txt json html
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 html json
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 html json
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 html json
Obsoletes:RFC 2543
Updated by:RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3261
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.

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

 
RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:June 2002
Formats:txt json html
Obsoletes:RFC 2543
Updated by:RFC 7984, RFC 8553
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 html json
Obsoletes:RFC 2543
Updated by:RFC 6157, RFC 8843, RFC 9143
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 html json
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, Ed., L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen.
Date:May 2002
Formats:txt html json
Updates:RFC 3032
Updated by:RFC 5462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3270
This document defines a flexible solution for support ofDifferentiated Services (Diff-Serv) over Multi-Protocol LabelSwitching (MPLS) networks.

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

 
RFC 3272 Overview and Principles of Internet Traffic Engineering
 
Authors:D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao.
Date:May 2002
Formats:txt json html
Obsoleted by:RFC 9522
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3272
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.
 
RFC 3273 Remote Network Monitoring Management Information Base for High Capacity Networks
 
Authors:S. Waldbusser.
Date:July 2002
Formats:txt json html
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 html json
Updated by:RFC 4055, RFC 4491, RFC 5480, RFC 5758, RFC 8692
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 html json
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 3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP)
 
Authors:H. Sjostrand, J. Buerkle, B. Srinivasan.
Date:June 2002
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3295
This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for theGeneral Switch Management Protocol (GSMP).
 
RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses
 
Authors:B. Haberman, D. Thaler.
Date:August 2002
Formats:txt json html
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 json pdf html
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 html json
Obsoleted by:RFC 8415
Updated by:RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3315
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
 
RFC 3320 Signaling Compression (SigComp)
 
Authors:R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg.
Date:January 2003
Formats:txt html json
Updated by:RFC 4896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3320
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as theSession Initiation Protocol (SIP) (RFC 3261) and the Real TimeStreaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of theSigComp message.

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

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

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

 
RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
 
Authors:C. Jennings, J. Peterson, M. Watson.
Date:November 2002
Formats:txt html json
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 3326 The Reason Header Field for the Session Initiation Protocol (SIP)
 
Authors:H. Schulzrinne, D. Oran, G. Camarillo.
Date:December 2002
Formats:txt json html
Updated by:RFC 8606, RFC 9366
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3326
For creating services, it is often useful to know why a SessionInitiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", orHERFP.
 
RFC 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
 
Authors:D. Willis, B. Hoeneisen.
Date:December 2002
Formats:txt json html
Updated by:RFC 5626
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3327
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of aUniform Resource Identifier (URI), such as Contact:<sip:alice@pc33.atlanta.com&rt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.
 
RFC 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP)
 
Authors:J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka.
Date:January 2003
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3329
This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
 
RFC 3344 IP Mobility Support for IPv4
 
Authors:C. Perkins, Ed..
Date:August 2002
Formats:txt json html
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 html json
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 json html
Obsoletes:RFC 2630, RFC 3211
Updated by:RFC 5754, RFC 8702
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 html json
Updates:RFC 2236
Updated by:RFC 4604
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3376
This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets*only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.

This document obsoletes RFC 2236.

 
RFC 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures
 
Authors:M. Mealling.
Date:October 2002
Formats:txt json html
Updated by:RFC 8958
Also:BCP 0065
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3405
This document is fifth in a series that is completely specified in"Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
 
RFC 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
 
Authors:D. Harrington, R. Presuhn, B. Wijnen.
Date:December 2002
Formats:txt json html
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 html json
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 json html
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 html json
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 html json
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 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
 
Authors:B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle.
Date:December 2002
Formats:txt json html
Updated by:RFC 8591
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3428
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.

This document proposes the MESSAGE method, an extension to theSession Initiation Protocol (SIP) that allows the transfer of InstantMessages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.

 
RFC 3435 Media Gateway Control Protocol (MGCP) Version 1.0
 
Authors:F. Andreasen, B. Foster.
Date:January 2003
Formats:txt json html
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 3436 Transport Layer Security over Stream Control Transmission Protocol
 
Authors:A. Jungmaier, E. Rescorla, M. Tuexen.
Date:December 2002
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3436
This document describes the usage of the Transport Layer Security(TLS) protocol, as defined in RFC 2246, over the Stream ControlTransmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.

The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.

Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses.

 
RFC 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
 
Authors:P. Agarwal, B. Akyol.
Date:January 2003
Formats:txt json html
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 html json
Updated by:RFC 3938
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3458
This memo describes a new RFC 2822 message header, "Message-Context".This header provides information about the context and presentation characteristics of a message.

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

 
RFC 3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
 
Authors:E. Burger.
Date:January 2003
Formats:txt html json
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 html json
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 json html
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 json html
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 html json
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 html json
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3469
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework.
 
RFC 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols
 
Authors:S. Hollenbeck, M. Rose, L. Masinter.
Date:January 2003
Formats:txt html json
Updated by:RFC 8996
Also:BCP 0070
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3470
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language(SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.

There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.

 
RFC 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
 
Authors:L. Berger, Ed..
Date:January 2003
Formats:txt html json
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 json html
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 json html
Updated by:RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003, RFC 6780, RFC 8359
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3473
This document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.
 
RFC 3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)
 
Authors:O. Aboul-Magd.
Date:March 2003
Formats:txt html json
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 json html
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 json html
Updated by:RFC 6107
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3477
Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to ResourceReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels(RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.
 
RFC 3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
 
Authors:M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach.
Date:February 2003
Formats:txt html json
Updated by:RFC 4896
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3485
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent.
 
RFC 3486 Compressing the Session Initiation Protocol (SIP)
 
Authors:G. Camarillo.
Date:February 2003
Formats:txt json html
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 json html
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 html json
Obsoletes:RFC 2060
Obsoleted by:RFC 9051
Updated by:RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3501
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.

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

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

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

 
RFC 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
 
Authors:M. Crispin.
Date:March 2003
Formats:txt json html
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 html json
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 json html
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 3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
 
Authors:W. Harold.
Date:April 2003
Formats:txt html json
Updated by:RFC 8553
Status:EXPERIMENTAL
DOI:10.17487/RFC 3529
XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP.An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.

This document specifies a how to use the Blocks Extensible ExchangeProtocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers.

 
RFC 3550 RTP: A Transport Protocol for Real-Time Applications
 
Authors:H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.
Date:July 2003
Formats:txt ps json pdf html
Obsoletes:RFC 1889
Updated by:RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860
Also:STD 0064
Status:INTERNET STANDARD
DOI:10.17487/RFC 3550
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP andRTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.

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

 
RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control
 
Authors:H. Schulzrinne, S. Casner.
Date:July 2003
Formats:txt ps json html pdf
Obsoletes:RFC 1890
Updated by:RFC 5761, RFC 7007, RFC 8860
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 3552 Guidelines for Writing RFC Text on Security Considerations
 
Authors:E. Rescorla, B. Korver.
Date:July 2003
Formats:txt html json
Updated by:RFC 8996, RFC 9416
Also:BCP 0072
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3552
All RFCs are required to have a Security Considerations section.Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good SecurityConsiderations section.
 
RFC 3555 MIME Type Registration of RTP Payload Formats
 
Authors:S. Casner, P. Hoschka.
Date:July 2003
Formats:txt json html
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 json html
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 html json
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 json html
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 3568 Known Content Network (CN) Request-Routing Mechanisms
 
Authors:A. Barbir, B. Cain, R. Nair, O. Spatscheck.
Date:July 2003
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 3568
This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or beforeDecember 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layerRequest-Routing, and Application-layer Request-Routing.
 
RFC 3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
 
Authors:T. Ogura, M. Maruyama, T. Yoshida.
Date:July 2003
Formats:txt html json
Updated by:RFC 8064
Status:INFORMATIONAL
DOI:10.17487/RFC 3572
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy(SONET/SDH).

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

 
RFC 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service)
 
Authors:B. Aboba.
Date:July 2003
Formats:txt json html
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 json html
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 json html
Updated by:RFC 7268
Status:INFORMATIONAL
DOI:10.17487/RFC 3580
This document provides suggestions on Remote Authentication Dial InUser Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normativeAppendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.
 
RFC 3588 Diameter Base Protocol
 
Authors:P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko.
Date:September 2003
Formats:txt json html
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 html json
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 json html
Updated by:RFC 5630
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3608
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.
 
RFC 3620 The TUNNEL Profile
 
Authors:D. New.
Date:October 2003
Formats:txt json html
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3620
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.
 
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2
 
Authors:D. Katz, K. Kompella, D. Yeung.
Date:September 2003
Formats:txt json html
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 html json
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 html json
Updated by:RFC 5691
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3640
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29WG11) is a working group in ISO that produced the MPEG-4 standard.MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non- multiplexed MPEG-4 elementary stream.
 
RFC 3641 Generic String Encoding Rules (GSER) for ASN.1 Types
 
Authors:S. Legg.
Date:October 2003
Formats:txt html json
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 3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
 
Authors:R. Siemborski.
Date:December 2003
Formats:txt json html
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 3656
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.

The Mailbox Update (MUPDATE) protocol allows a group of InternetMessage Access Protocol (IMAP) or Post Office Protocol - Version 3(POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

 
RFC 3658 Delegation Signer (DS) Resource Record (RR)
 
Authors:O. Gudmundsson.
Date:December 2003
Formats:txt html json
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 3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes
 
Authors:R. Droms.
Date:January 2004
Formats:txt html json
Updated by:RFC 8910
Status:INFORMATIONAL
DOI:10.17487/RFC 3679
Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic HostConfiguration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future.

The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

 
RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations
 
Authors:J. Rosenberg.
Date:March 2004
Formats:txt html json
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 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists
 
Authors:M. Rose.
Date:March 2004
Formats:txt json html
Updated by:RFC 9245
Also:BCP 0083
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3683
All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion.An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF.
 
RFC 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
 
Authors:R. Ogier, F. Templin, M. Lewis.
Date:February 2004
Formats:txt html json
Updated by:RFC 9141
Status:EXPERIMENTAL
DOI:10.17487/RFC 3684
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree(providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification ofDijkstra's algorithm. To minimize overhead, each node reports only*part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results inHELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.
 
RFC 3693 Geopriv Requirements
 
Authors:J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk.
Date:February 2004
Formats:txt json html
Updated by:RFC 6280, RFC 7459
Status:INFORMATIONAL
DOI:10.17487/RFC 3693
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.

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

 
RFC 3694 Threat Analysis of the Geopriv Protocol
 
Authors:M. Danley, D. Mulligan, J. Morris, J. Peterson.
Date:February 2004
Formats:txt html json
Updated by:RFC 6280
Status:INFORMATIONAL
DOI:10.17487/RFC 3694
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements.
 
RFC 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules
 
Authors:K. Zeilenga, Ed..
Date:February 2004
Formats:txt html json
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 json html
Updated by:RFC 4104
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3703
This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that usesLightweight Directory Access Protocol (LDAP) as its access protocol.This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them.
 
RFC 3704 Ingress Filtering for Multihomed Networks
 
Authors:F. Baker, P. Savola.
Date:March 2004
Formats:txt html json
Updates:RFC 2827
Updated by:RFC 8704
Also:BCP 0084
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3704
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting theInternet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827.
 
RFC 3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
 
Authors:S. Santesson, R. Housley, T. Freeman.
Date:February 2004
Formats:txt html json
Obsoleted by:RFC 9399
Updated by:RFC 6170
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3709
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.
 
RFC 3710 An IESG charter
 
Authors:H. Alvestrand.
Date:February 2004
Formats:txt html json
Updated by:RFC 3932, RFC 5742, RFC 8717
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 html json
Updated by:RFC 5506, RFC 6904, RFC 9335
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 html json
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 html json
Updated by:RFC 7143
Status:INFORMATIONAL
DOI:10.17487/RFC 3721
This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.
 
RFC 3723 Securing Block Storage Protocols over IP
 
Authors:B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino.
Date:April 2004
Formats:txt json html
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3723
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small ComputerSystem Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (InternetStorage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.
 
RFC 3748 Extensible Authentication Protocol (EAP)
 
Authors:B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed..
Date:June 2004
Formats:txt json html
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 json html
Updated by:RFC 8447, RFC 8996
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 json html
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 html json
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 json html
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 3767 Securely Available Credentials Protocol
 
Authors:S. Farrell, Ed..
Date:June 2004
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3767
This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support forTLS and/or DIGEST-MD5 (through BEEP).
 
RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
 
Authors:J. Arkko, V. Devarapalli, F. Dupont.
Date:June 2004
Formats:txt html json
Updated by:RFC 4877
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3776
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
 
RFC 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:J. Galvin, Ed..
Date:June 2004
Formats:txt html json
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 json html
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 json html
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 html json
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 html json
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3811
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used MultiprotocolLabel Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.
 
RFC 3821 Fibre Channel Over TCP/IP (FCIP)
 
Authors:M. Rajagopal, E. Rodriguez, R. Weber.
Date:July 2004
Formats:txt html json
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3821
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
 
RFC 3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
 
Authors:D. Peterson.
Date:July 2004
Formats:txt json html
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 html json
Updated by:RFC 6335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3828
This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP.
 
RFC 3830 MIKEY: Multimedia Internet KEYing
 
Authors:J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman.
Date:August 2004
Formats:txt html json
Updated by:RFC 4738, RFC 6309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3830
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail.

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

 
RFC 3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV
 
Authors:W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome.
Date:July 2004
Formats:txt json html
Updated by:RFC 8553
Status:EXPERIMENTAL
DOI:10.17487/RFC 3832
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) viaDNS SRV. It defines the DNS SRV Resource Records for SLP DirectoryAgent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.
 
RFC 3834 Recommendations for Automatic Responses to Electronic Mail
 
Authors:K. Moore.
Date:August 2004
Formats:txt html json
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 html json
Updated by:RFC 6381
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3839
This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format.
 
RFC 3843 RObust Header Compression (ROHC): A Compression Profile for IP
 
Authors:L-E. Jonsson, G. Pelletier.
Date:June 2004
Formats:txt html json
Updated by:RFC 4815
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3843
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload),IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines aROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.
 
RFC 3852 Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:July 2004
Formats:txt html json
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 3856 A Presence Event Package for the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg.
Date:August 2004
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3856
This document describes the usage of the Session Initiation Protocol(SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with theCommon Presence Profile (CPP) framework.
 
RFC 3864 Registration Procedures for Message Header Fields
 
Authors:G. Klyne, M. Nottingham, J. Mogul.
Date:September 2004
Formats:txt json html
Updated by:RFC 9110
Also:BCP 0090
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3864
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
 
RFC 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
 
Authors:G. Jones, Ed..
Date:September 2004
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 3871
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.
 
RFC 3887 Message Tracking Query Protocol
 
Authors:T. Hansen.
Date:September 2004
Formats:txt html json
Updated by:RFC 8553, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3887
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet.
 
RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism
 
Authors:R. Sparks.
Date:September 2004
Formats:txt html json
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 3903 Session Initiation Protocol (SIP) Extension for Event State Publication
 
Authors:A. Niemi, Ed..
Date:October 2004
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3903
This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information.

The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.

 
RFC 3920 Extensible Messaging and Presence Protocol (XMPP): Core
 
Authors:P. Saint-Andre, Ed..
Date:October 2004
Formats:txt json html
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 3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
 
Authors:T. Hardie.
Date:October 2004
Formats:txt json html
Updated by:RFC 8717
Status:EXPERIMENTAL
DOI:10.17487/RFC 3929
This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed.
 
RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
 
Authors:J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed..
Date:March 2005
Formats:txt json html
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 3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
 
Authors:R. Friend.
Date:November 2004
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 3943
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol.
 
RFC 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture
 
Authors:E. Mannie, Ed..
Date:October 2004
Formats:txt html json
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 json html
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 json html
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 3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
 
Authors:L. Daigle, A. Newton.
Date:January 2005
Formats:txt html json
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3958
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines aDynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
 
RFC 3961 Encryption and Checksum Specifications for Kerberos 5
 
Authors:K. Raeburn.
Date:February 2005
Formats:txt html json
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 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5
 
Authors:K. Raeburn.
Date:February 2005
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3962
The United States National Institute of Standards and Technology(NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the oldData Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite.
 
RFC 3966 The tel URI for Telephone Numbers
 
Authors:H. Schulzrinne.
Date:December 2004
Formats:txt json html
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 json html
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 html json
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 3970 A Traffic Engineering (TE) MIB
 
Authors:K. Kompella.
Date:January 2005
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3970
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for Traffic Engineered(TE) Tunnels; for example, Multi-Protocol Label Switched Paths.
 
RFC 3971 SEcure Neighbor Discovery (SEND)
 
Authors:J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander.
Date:March 2005
Formats:txt html json
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 json html
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 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
 
Authors:A. Adams, J. Nicholas, W. Siadak.
Date:January 2005
Formats:txt json html
Updated by:RFC 8736, RFC 9436
Status:EXPERIMENTAL
DOI:10.17487/RFC 3973
This document specifies Protocol Independent Multicast - Dense Mode(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information.
 
RFC 3977 Network News Transfer Protocol (NNTP)
 
Authors:C. Feather.
Date:October 2006
Formats:txt json html
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 html json
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 html json
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 html json
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 3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
 
Authors:A. Newton, M. Sanz.
Date:January 2005
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3983
This document specifies how to use the Blocks Extensible ExchangeProtocol (BEEP) as the application transport substrate for theInternet Registry Information Service (IRIS).
 
RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
 
Authors:S. Bryant, Ed., P. Pate, Ed..
Date:March 2005
Formats:txt html json
Updated by:RFC 5462
Status:INFORMATIONAL
DOI:10.17487/RFC 3985
This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
 
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
 
Authors:T. Berners-Lee, R. Fielding, L. Masinter.
Date:January 2005
Formats:txt json html
Obsoletes:RFC 2732, RFC 2396, RFC 1808
Updates:RFC 1738
Updated by:RFC 6874, RFC 7320, RFC 8820
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 json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4002
This document registers the Enumservices 'web' and 'ft' by using theURI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761).
 
RFC 4007 IPv6 Scoped Address Architecture
 
Authors:S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill.
Date:March 2005
Formats:txt json html
Updated by:RFC 7346
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4007
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
 
RFC 4012 Routing Policy Specification Language next generation (RPSLng)
 
Authors:L. Blunk, J. Damas, F. Parent, A. Robachevsky.
Date:March 2005
Formats:txt json html
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 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option
 
Authors:R. Droms, J. Schnizlein.
Date:February 2005
Formats:txt html json
Updated by:RFC 9445
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4014
The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client.
 
RFC 4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
 
Authors:M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry.
Date:April 2005
Formats:txt html json
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4018
The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide.
 
RFC 4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
 
Authors:G. Pelletier.
Date:April 2005
Formats:txt html json
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 html json
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 json html
Updated by:RFC 5332
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4023
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic RoutingEncapsulation). Each of these is applicable in some circumstances.
 
RFC 4033 DNS Security Introduction and Requirements
 
Authors:R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.
Date:March 2005
Formats:txt json html
Obsoletes:RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Updates:RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226
Updated by:RFC 6014, RFC 6840
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4033
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that theDNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.
 
RFC 4034 Resource Records for the DNS Security Extensions
 
Authors:R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.
Date:March 2005
Formats:txt html json
Obsoletes:RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Updates:RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226
Updated by:RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4034
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

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

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

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

 
RFC 4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
 
Authors:W. Sawyer.
Date:April 2005
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4036
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP)-based management of Data-over-CableService Interface Specification (DOCSIS)-compliant Cable ModemTermination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The DifferentiatedServices MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification.
 
RFC 4048 RFC 1888 Is Obsolete
 
Authors:B. Carpenter.
Date:April 2005
Formats:txt json html
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 json html
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 json html
Obsoleted by:RFC 8711
Updated by:RFC 4371, RFC 7691
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 html json
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 json html
Updated by:RFC 8271, RFC 8537, RFC 8796
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 4097 Middlebox Communications (MIDCOM) Protocol Evaluation
 
Authors:M. Barnes, Ed..
Date:June 2005
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4097
This document provides an evaluation of the applicability of SNMP(Simple Network Management Protocol), RSIP (Realm Specific InternetProtocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.
 
RFC 4102 Registration of the text/red MIME Sub-Type
 
Authors:P. Jones.
Date:June 2005
Formats:txt html json
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 4103 RTP Payload for Text Conversation
 
Authors:G. Hellstrom, P. Jones.
Date:June 2005
Formats:txt html json
Obsoletes:RFC 2793
Updated by:RFC 9071
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4103
This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separateRTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.

 
RFC 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
 
Authors:L. Fang, Ed..
Date:July 2005
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4111
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements.In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.
 
RFC 4119 A Presence-based GEOPRIV Location Object Format
 
Authors:J. Peterson.
Date:December 2005
Formats:txt json html
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 json html
Obsoletes:RFC 1510
Updated by:RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4120
This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.
 
RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
 
Authors:L. Zhu, K. Jaganathan, S. Hartman.
Date:July 2005
Formats:txt json html
Updates:RFC 1964
Updated by:RFC 5896, 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 4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus
 
Authors:S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson.
Date:September 2005
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4131
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP) based management of the Baseline PrivacyPlus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable ServiceInterface Specification) compliant Cable Modems and Cable ModemTermination Systems.
 
RFC 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
 
Authors:P. Sarolahti, M. Kojo.
Date:August 2005
Formats:txt json html
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 json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4143
This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.IFax is "facsimile using Internet mail". For this use, the DomainName System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address.
 
RFC 4145 TCP-Based Media Transport in the Session Description Protocol (SDP)
 
Authors:D. Yon, G. Camarillo.
Date:September 2005
Formats:txt html json
Updated by:RFC 4572
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4145
This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment.
 
RFC 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS)
 
Authors:H.J. Lee, J.H. Yoon, J.I. Lee.
Date:August 2005
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4162
This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm.
 
RFC 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg, H. Schulzrinne, G. Camarillo.
Date:October 2005
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4168
This document specifies a mechanism for usage of SCTP (the StreamControl Transmission Protocol) as the transport mechanism between SIP(Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.
 
RFC 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking
 
Authors:C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards.
Date:September 2005
Formats:txt json html
Updated by:RFC 6172, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4172
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
 
RFC 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
 
Authors:P. Sarkar, D. Missimer, C. Sapuntzakis.
Date:September 2005
Formats:txt json html
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4173
Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol.The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.
 
RFC 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
 
Authors:C. Monia, J. Tseng, K. Gibbons.
Date:September 2005
Formats:txt html json
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4174
This document describes the Dynamic Host Configuration Protocol(DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre ChannelProtocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network.
 
RFC 4175 RTP Payload Format for Uncompressed Video
 
Authors:L. Gharai, C. Perkins.
Date:September 2005
Formats:txt html json
Updated by:RFC 4421
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4175
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time TransportProtocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITUBT.601, and standards from the Society of Motion Picture andTelevision Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed.
 
RFC 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files
 
Authors:Y. Shafranovich.
Date:October 2005
Formats:txt html json
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 html json
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 json html
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 json html
Updated by:RFC 5448, RFC 9048
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 json html
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 json html
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 html json
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 json html
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 json html
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4207
This document details the Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages.
 
RFC 4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
 
Authors:A. Fredette, Ed., J. Lang, Ed..
Date:October 2005
Formats:txt html json
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4209
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link InterfaceRequirements" described in a companion document.
 
RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
 
Authors:C. Adams, S. Farrell, T. Kause, T. Mononen.
Date:September 2005
Formats:txt html json
Obsoletes:RFC 2510
Updated by:RFC 6712, RFC 9480, RFC 9481
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 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
 
Authors:J. Schaad.
Date:September 2005
Formats:txt html json
Obsoletes:RFC 2511
Updated by:RFC 9045
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4211
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via aRegistration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol.
 
RFC 4217 Securing FTP with TLS
 
Authors:P. Ford-Hutchinson.
Date:October 2005
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4217
This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP SecurityExtensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for SecureSMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File TransferProtocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions".

 
RFC 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
 
Authors:G. Choudhury, Ed..
Date:October 2005
Formats:txt json html
Updated by:RFC 9454
Also:BCP 0112
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4222
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest PathFirst (OSPF) Version 2 protocol. The methods include processing OSPFHellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures.
 
RFC 4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
 
Authors:E. O'Tuathail, M. Rose.
Date:January 2006
Formats:txt json html
Obsoletes:RFC 3288
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4227
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.

The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote ProcedureCalling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.

 
RFC 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
 
Authors:K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom.
Date:January 2006
Formats:txt json html
Obsoletes:RFC 3057
Updated by:RFC 5133
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4233
This document defines a protocol for backhauling of IntegratedServices Digital Network (ISDN) Q.921 User messages over IP using theStream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller(MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057.

 
RFC 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg, H. Schulzrinne, R. Mahy, Ed..
Date:November 2005
Formats:txt html json
Updated by:RFC 7463, RFC 8996
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 html json
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 json html
Updated by:RFC 8268, RFC 9142, RFC 9519
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 json html
Updated by:RFC 8308, RFC 9141
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 html json
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 html json
Updated by:RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142
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 json html
Updated by:RFC 8308
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4254
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

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

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

 
RFC 4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
 
Authors:J. Walker, A. Kulkarni, Ed..
Date:December 2005
Formats:txt json html
Updates:RFC 2748
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4261
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over theInternet.

This document also updates RFC 2748 by modifying the contents of theClient-Accept message.

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

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

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

This document obsoletes RFC 1771.

 
RFC 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
 
Authors:P. Eronen, Ed., H. Tschofenig, Ed..
Date:December 2005
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4279
This document specifies three sets of new ciphersuites for theTransport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client.
 
RFC 4287 The Atom Syndication Format
 
Authors:M. Nottingham, Ed., R. Sayre, Ed..
Date:December 2005
Formats:txt html json
Updated by:RFC 5988
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4287
This document specifies Atom, an XML-based Web content and metadata syndication format.
 
RFC 4291 IP Version 6 Addressing Architecture
 
Authors:R. Hinden, S. Deering.
Date:February 2006
Formats:txt json html
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 json html
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 json html
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 html json
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 4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)
 
Authors:M. Patrick, W. Murwin.
Date:January 2006
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4323
This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and CableModem Termination Systems (CMTSs) conforming to the Data over CableSystem (DOCSIS) specifications versions 1.1 and 2.0.
 
RFC 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
 
Authors:G. Fairhurst, B. Collini-Nocker.
Date:December 2005
Formats:txt html json
Updated by:RFC 7280
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4326
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

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

 
RFC 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
 
Authors:D. Papadimitriou, Ed..
Date:January 2006
Formats:txt json html
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 html json
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 json html
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 html json
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 html json
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 json html
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 4343 Domain Name System (DNS) Case Insensitivity Clarification
 
Authors:D. Eastlake 3rd.
Date:January 2006
Formats:txt json html
Updates:RFC 1034, RFC 1035, RFC 2181
Updated by:RFC 5890
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4343
Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181.
 
RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1
 
Authors:T. Dierks, E. Rescorla.
Date:April 2006
Formats:txt json html
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:HISTORIC
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 json html
Obsoleted by:RFC 6347
Updated by:RFC 5746, RFC 7507
Status:HISTORIC
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 html json
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 html json
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4349
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelHigh-Level Data Link Control (HDLC) frames over L2TPv3.
 
RFC 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms
 
Authors:R. Brandner, L. Conroy, R. Stastny.
Date:January 2006
Formats:txt html json
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4355
This document registers the Enumservices "email", "fax", "sms","ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761.
 
RFC 4360 BGP Extended Communities Attribute
 
Authors:S. Sangli, D. Tappan, Y. Rekhter.
Date:February 2006
Formats:txt html json
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 html json
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 json html
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 html json
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 json html
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 html json
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 html json
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 html json
Updated by:RFC 5586
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4385
This document describes the preferred design of a PseudowireEmulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated ChannelHeader. The design of these fields is chosen so that an MPLS LabelSwitching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.
 
RFC 4386 Internet X.509 Public Key Infrastructure Repository Locator Service
 
Authors:S. Boeyen, P. Hallam-Baker.
Date:February 2006
Formats:txt json html
Updated by:RFC 8553
Status:EXPERIMENTAL
DOI:10.17487/RFC 4386
This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.
 
RFC 4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
 
Authors:P. Gutmann, Ed..
Date:February 2006
Formats:txt json html
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4387
The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists(CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
 
RFC 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery
 
Authors:R. Woundy, K. Kinnear.
Date:February 2006
Formats:txt html json
Updated by:RFC 6148
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4388
A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided toDHCPv4 clients. Other processes and devices that already make use ofDHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.
 
RFC 4391 Transmission of IP over InfiniBand (IPoIB)
 
Authors:J. Chu, V. Kashyap.
Date:April 2006
Formats:txt html json
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 json html
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 html json
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 html json
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 json html
Updated by:RFC 7134
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4412
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely,"Resource-Priority" and "Accept-Resource-Priority". The"Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior ofIP routers.
 
RFC 4415 IANA Registration for Enumservice Voice
 
Authors:R. Brandner, L. Conroy, R. Stastny.
Date:February 2006
Formats:txt html json
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4415
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in theENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.
 
RFC 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
 
Authors:M. Friedl, N. Provos, W. Simpson.
Date:March 2006
Formats:txt html json
Updated by:RFC 8270
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4419
This memo describes a new key exchange method for the Secure Shell(SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.
 
RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
 
Authors:N. Moore.
Date:April 2006
Formats:txt html json
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 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
 
Authors:B. Harris.
Date:March 2006
Formats:txt json html
Updated by:RFC 9142
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4432
This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems.
 
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
 
Authors:A. Conta, S. Deering, M. Gupta, Ed..
Date:March 2006
Formats:txt html json
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 html json
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 json html
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 json html
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4454
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use theL2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over anIP network.
 
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
 
Authors:T. Bates, E. Chen, R. Chandra.
Date:April 2006
Formats:txt html json
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 json html
Updated by:RFC 8119
Status:INFORMATIONAL
DOI:10.17487/RFC 4458
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
 
RFC 4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
 
Authors:J. Hutzelman, J. Salowey, J. Galbraith, V. Welch.
Date:May 2006
Formats:txt html json
Updated by:RFC 8732, RFC 9142
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4462
The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.

This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.

This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange.

 
RFC 4466 Collected Extensions to IMAP4 ABNF
 
Authors:A. Melnikov, C. Daboo.
Date:April 2006
Formats:txt html json
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 html json
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 json html
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 json html
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 html json
Updated by:RFC 8203, RFC 9003
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 html json
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 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG
 
Authors:J. Elwell, F. Derks, P. Mourot, O. Rousseau.
Date:May 2006
Formats:txt html json
Updated by:RFC 8996
Also:BCP 0117
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4497
This document specifies interworking between the Session InitiationProtocol (SIP) and QSIG within corporate telecommunication networks(also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) withinPrivate Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.
 
RFC 4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
 
Authors:O. Levin, A. Johnston.
Date:May 2006
Formats:txt json html
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 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
 
Authors:R. Harrison, Ed..
Date:June 2006
Formats:txt html json
Obsoletes:RFC 2251, RFC 2829, RFC 2830
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4513
This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.

This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and theSimple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.

This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.

This document, together with other documents in the LDAP TechnicalSpecification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830.

 
RFC 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation
 
Authors:K. Zeilenga.
Date:June 2006
Formats:txt json html
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 4531
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.
 
RFC 4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
 
Authors:M. Stiemerling, J. Quittek, C. Cadar.
Date:May 2006
Formats:txt html json
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 4540
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.
 
RFC 4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
 
Authors:F. Baker, J. Polk.
Date:May 2006
Formats:txt json html
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 4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces
 
Authors:D. Raftus, E. Cardona.
Date:June 2006
Formats:txt json html
Obsoletes:RFC 2670
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4546
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP) based management of the Radio Frequency(RF) interfaces for systems compliant with the Data Over CableService Interface Specifications (DOCSIS).
 
RFC 4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems
 
Authors:A. Ahmad, G. Nakanishi.
Date:June 2006
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4547
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification(DOCSIS) compliant Cable Modems and Cable Modem Termination Systems.This MIB is defined as an extension to the DOCSIS Cable Device MIB.

This memo specifies a MIB module in a manner that is compliant to theStructure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards.

 
RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
 
Authors:L. Zhu, B. Tung.
Date:June 2006
Formats:txt json html
Updated by:RFC 6112, RFC 8062, RFC 8636
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 json html
Updated by:RFC 6309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4563
This memo specifies a new Type (the Key ID Information Type) for theGeneral Extension Payload in the Multimedia Internet KEYing (MIKEY)Protocol. This is used in, for example, the MultimediaBroadcast/Multicast Service specified in the Third GenerationPartnership Project.
 
RFC 4582 The Binary Floor Control Protocol (BFCP)
 
Authors:G. Camarillo, J. Ott, K. Drage.
Date:November 2006
Formats:txt json html
Obsoleted by:RFC 8855
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4582
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.

This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.

 
RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
 
Authors:J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey.
Date:July 2006
Formats:txt html json
Updated by:RFC 5506, RFC 8108
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4585
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of theReal-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to theAudio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.
 
RFC 4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
 
Authors:M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau.
Date:August 2006
Formats:txt html json
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4591
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelFrame Relay over L2TPv3, including frame encapsulation, virtual- circuit creation and deletion, and status change notification.
 
RFC 4594 Configuration Guidelines for DiffServ Service Classes
 
Authors:J. Babiarz, K. Chan, F. Baker.
Date:August 2006
Formats:txt html json
Updated by:RFC 5865, RFC 8622
Status:INFORMATIONAL
DOI:10.17487/RFC 4594
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them usingDifferentiated Services Code Points (DSCPs), traffic conditioners,Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
 
RFC 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
 
Authors:B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
Date:August 2006
Formats:txt pdf html json
Obsoletes:RFC 2362
Obsoleted by:RFC 7761
Updated by:RFC 5059, RFC 5796, RFC 6226
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4601
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.

This document obsoletes RFC 2362, an Experimental version of PIM-SM.

 
RFC 4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
 
Authors:E. Mannie, D. Papadimitriou.
Date:August 2006
Formats:txt json html
Obsoletes:RFC 3946
Updated by:RFC 6344
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4606
This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used.

 
RFC 4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents
 
Authors:M. Duke, R. Braden, W. Eddy, E. Blanton.
Date:September 2006
Formats:txt html json
Obsoleted by:RFC 7414
Updated by:RFC 6247
Status:INFORMATIONAL
DOI:10.17487/RFC 4614
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.
 
RFC 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
 
Authors:K. Zeilenga, Ed..
Date:August 2006
Formats:txt json html
Updates:RFC 2595
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4616
This document defines a simple clear-text user/password SimpleAuthentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command.
 
RFC 4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists
 
Authors:S. Hartman.
Date:August 2006
Formats:txt json html
Updated by:RFC 8717
Status:EXPERIMENTAL
DOI:10.17487/RFC 4633
Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managingInternet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be.
 
RFC 4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems
 
Authors:R. Woundy, K. Marez.
Date:December 2006
Formats:txt html json
Obsoletes:RFC 2669
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4639
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of Data OverCable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.

This memo obsoletes RFC 2669.

 
RFC 4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)
 
Authors:K. Murchison, J. Vinocur, C. Newman.
Date:October 2006
Formats:txt html json
Updated by:RFC 8143, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4642
This memo defines an extension to the Network News Transfer Protocol(NNTP) that allows an NNTP client and server to use Transport LayerSecurity (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible.
 
RFC 4656 A One-way Active Measurement Protocol (OWAMP)
 
Authors:S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas.
Date:September 2006
Formats:txt html json
Updated by:RFC 7717, RFC 7718, RFC 8545
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4656
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources(such as GPS and CDMA). OWAMP enables the interoperability of these measurements.
 
RFC 4660 Functional Description of Event Notification Filtering
 
Authors:H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena.
Date:September 2006
Formats:txt json html
Updated by:RFC 6665
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4660
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed.

 
RFC 4680 TLS Handshake Message for Supplemental Data
 
Authors:S. Santesson.
Date:October 2006
Formats:txt json html
Updates:RFC 4346
Updated by:RFC 8447, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4680
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both theTLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types.
 
RFC 4681 TLS User Mapping Extension
 
Authors:S. Santesson, A. Medvinsky, J. Ball.
Date:October 2006
Formats:txt json html
Updates:RFC 4346
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4681
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future.
 
RFC 4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices
 
Authors:E. Nechamkin, J-F. Mule.
Date:December 2006
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4682
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices.
 
RFC 4697 Observed DNS Resolution Misbehavior
 
Authors:M. Larson, P. Barber.
Date:October 2006
Formats:txt html json
Updated by:RFC 9520
Also:BCP 0123
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4697
This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers.
 
RFC 4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
 
Authors:M. Stapp, T. Lemon, A. Gustafsson.
Date:October 2006
Formats:txt json html
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4701
It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct ResourceRecord (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR.
 
RFC 4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
 
Authors:A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman, Y. Kim.
Date:October 2006
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4712
This memo specifies two transport mappings of the Real-TimeApplication Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the SimpleNetwork Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
 
RFC 4716 The Secure Shell (SSH) Public Key File Format
 
Authors:J. Galbraith, R. Thayer.
Date:November 2006
Formats:txt html json
Updated by:RFC 9519
Status:INFORMATIONAL
DOI:10.17487/RFC 4716
This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell(SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints.

 
RFC 4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
 
Authors:R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed..
Date:November 2006
Formats:txt json html
Updated by:RFC 5641
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4719
This document describes the transport of Ethernet frames over theLayer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport ofEthernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network.
 
RFC 4724 Graceful Restart Mechanism for BGP
 
Authors:S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter.
Date:January 2007
Formats:txt json html
Updated by:RFC 8538
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4724
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful RestartCapability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.

The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document).

 
RFC 4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned
 
Authors:A. Melnikov, D. Cridland.
Date:November 2006
Formats:txt json html
Updated by:RFC 9394
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4731
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages.
 
RFC 4732 Internet Denial-of-Service Considerations
 
Authors:M. Handley, Ed., E. Rescorla, Ed., IAB.
Date:December 2006
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4732
This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.
 
RFC 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
 
Authors:H. Schulzrinne, T. Taylor.
Date:December 2006
Formats:txt html json
Obsoletes:RFC 2833
Updated by:RFC 4734, RFC 5244
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4733
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets.It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined inRFC 2833, but retains only the most basic event codes. It sets up anIANA registry to which other event code assignments may be added.Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events.The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.

 
RFC 4737 Packet Reordering Metrics
 
Authors:A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser.
Date:November 2006
Formats:txt html json
Updated by:RFC 6248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4737
This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included.An appendix gives extended definitions for evaluating order with packet fragmentation.
 
RFC 4743 Using NETCONF over the Simple Object Access Protocol (SOAP)
 
Authors:T. Goddard.
Date:December 2006
Formats:txt json html
Updated by:RFC 8996
Status:HISTORIC
DOI:10.17487/RFC 4743
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of theSimple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange ExtensibleProtocol (BEEP) bindings for NETCONF.
 
RFC 4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
 
Authors:E. Lear, K. Crozier.
Date:December 2006
Formats:txt html json
Updated by:RFC 8996
Status:HISTORIC
DOI:10.17487/RFC 4744
This document specifies an application protocol mapping for theNetwork Configuration Protocol (NETCONF) over the Blocks ExtensibleExchange Protocol (BEEP).
 
RFC 4749 RTP Payload Format for the G.729.1 Audio Codec
 
Authors:A. Sollaud.
Date:October 2006
Formats:txt html json
Updated by:RFC 5459
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4749
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) G.729.1 audio codec. A media type registration is included for this payload format.
 
RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
 
Authors:K. Jaganathan, L. Zhu, J. Brezak.
Date:December 2006
Formats:txt json html
Updated by:RFC 6649
Status:HISTORIC
DOI:10.17487/RFC 4757
The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existingWindows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types.

 
RFC 4760 Multiprotocol Extensions for BGP-4
 
Authors:T. Bates, R. Chandra, D. Katz, Y. Rekhter.
Date:January 2007
Formats:txt html json
Obsoletes:RFC 2858
Updated by:RFC 7606
Status:DRAFT STANDARD
DOI:10.17487/RFC 4760
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6,IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
 
RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
 
Authors:K. Kompella, Ed., Y. Rekhter, Ed..
Date:January 2007
Formats:txt html json
Updated by:RFC 5462, RFC 8395, RFC 8614
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4761
Virtual Private LAN Service (VPLS), also known as Transparent LANService and Virtual Private Switched Network service, is a usefulService Provider offering. The service offers a Layer 2 VirtualPrivate Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network.

 
RFC 4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information
 
Authors:J. Livingood, R. Shockey.
Date:November 2006
Formats:txt html json
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4769
This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using theURI scheme 'sip' as per the IANA registration process defined in theENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists.
 
RFC 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
 
Authors:S. Floyd.
Date:November 2006
Formats:txt html json
Updated by:RFC 6040
Also:BCP 0124
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4774
There have been a number of proposals for alternate semantics for theExplicit Congestion Notification (ECN) field in the IP header[RFC3168]. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics.
 
RFC 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
 
Authors:H. Schulzrinne.
Date:November 2006
Formats:txt json html
Obsoletes:RFC 4676
Updated by:RFC 5774, RFC 6848
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4776
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.
 
RFC 4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)
 
Authors:U. Blumenthal, P. Goel.
Date:January 2007
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4785
This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport LayerSecurity (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted.
 
RFC 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
 
Authors:F. Audet, Ed., C. Jennings.
Date:January 2007
Formats:txt json html
Updated by:RFC 6888, RFC 7857
Also:BCP 0127
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4787
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handlingUnicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
 
RFC 4788 Enhancements to RTP Payload Formats for EVRC Family Codecs
 
Authors:Q. Xie, R. Kapoor.
Date:January 2007
Formats:txt html json
Updates:RFC 3558
Updated by:RFC 5188
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4788
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth.
 
RFC 4791 Calendaring Extensions to WebDAV (CalDAV)
 
Authors:C. Daboo, B. Desruisseaux, L. Dusseault.
Date:March 2007
Formats:txt html json
Updated by:RFC 5689, RFC 6638, RFC 6764, RFC 7809, RFC 7953, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4791
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV.
 
RFC 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization
 
Authors:L. Nguyen, A. Roy, A. Zinin.
Date:March 2007
Formats:txt json html
Updated by:RFC 9454
Status:INFORMATIONAL
DOI:10.17487/RFC 4811
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize theirLSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.

This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard.

 
RFC 4819 Secure Shell Public Key Subsystem
 
Authors:J. Galbraith, J. Van Dyke, J. Bright.
Date:March 2007
Formats:txt json html
Updated by:RFC 9519
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4819
Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution.No common key management solution exists in current implementations.This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.

A public key may also be associated with various restrictions, including a mandatory command or subsystem.

 
RFC 4821 Packetization Layer Path MTU Discovery
 
Authors:M. Mathis, J. Heffner.
Date:March 2007
Formats:txt json html
Updated by:RFC 8899
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4821
This document describes a robust method for Path MTU Discovery(PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specifyICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.
 
RFC 4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet
 
Authors:T. Harding, R. Scott.
Date:April 2007
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4823
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol(FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 orUN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
 
RFC 4844 The RFC Series and RFC Editor
 
Authors:L. Daigle, Ed., Internet Architecture Board.
Date:July 2007
Formats:txt html json
Obsoleted by:RFC 8729
Updated by:RFC 5741
Status:INFORMATIONAL
DOI:10.17487/RFC 4844
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate.
 
RFC 4846 Independent Submissions to the RFC Editor
 
Authors:J. Klensin, Ed., D. Thaler, Ed..
Date:July 2007
Formats:txt json html
Updated by:RFC 5744
Status:INFORMATIONAL
DOI:10.17487/RFC 4846
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
 
RFC 4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
 
Authors:N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou.
Date:May 2007
Formats:txt html json
Updated by:RFC 8996, RFC 9427
Status:INFORMATIONAL
DOI:10.17487/RFC 4851
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the TransportLayer Security (TLS) to establish a mutually authenticated tunnel.Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.
 
RFC 4855 Media Type Registration of RTP Payload Formats
 
Authors:S. Casner.
Date:February 2007
Formats:txt html json
Obsoletes:RFC 3555
Updated by:RFC 8851
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4855
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission.
 
RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
 
Authors:T. Narten, E. Nordmark, W. Simpson, H. Soliman.
Date:September 2007
Formats:txt html json
Obsoletes:RFC 2461
Updated by:RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131
Status:DRAFT STANDARD
DOI:10.17487/RFC 4861
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.
 
RFC 4862 IPv6 Stateless Address Autoconfiguration
 
Authors:S. Thomson, T. Narten, T. Jinmei.
Date:September 2007
Formats:txt json html
Obsoletes:RFC 2462
Updated by:RFC 7527
Status:DRAFT STANDARD
DOI:10.17487/RFC 4862
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the DuplicateAddress Detection procedure to verify the uniqueness of the addresses on a link.
 
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures
 
Authors:E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas.
Date:May 2007
Formats:txt html json
Obsoletes:RFC 4870
Obsoleted by:RFC 6376
Updated by:RFC 5672
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4871
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".
 
RFC 4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
 
Authors:J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed..
Date:May 2007
Formats:txt json html
Updates:RFC 3471
Updated by:RFC 4873, RFC 6780, RFC 9270
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4872
This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description ofGMPLS recovery can be found in a companion document, RFC 4426.
 
RFC 4873 GMPLS Segment Recovery
 
Authors:L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel.
Date:May 2007
Formats:txt json html
Updates:RFC 3473, RFC 4872
Updated by:RFC 9270
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4873
This document describes protocol specific procedures for GMPLS(Generalized Multi-Protocol Label Switching) RSVP-TE (ResourceReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).Implications and interactions with fast reroute are also addressed.This document also updates the handling of NOTIFY_REQUEST objects.
 
RFC 4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
 
Authors:CY. Lee, A. Farrel, S. De Cnodder.
Date:April 2007
Formats:txt html json
Updates:RFC 3209, RFC 3473
Updated by:RFC 6001, RFC 8390
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4874
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering(RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSPTunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Resource ReserVationProtocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared RiskLink Groups (SRLGs) can be excluded is also specified in this document.

 
RFC 4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
 
Authors:R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed..
Date:May 2007
Formats:txt html json
Updated by:RFC 6510
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4875
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TELSP is outside the scope of this document.

 
RFC 4880 OpenPGP Message Format
 
Authors:J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer.
Date:November 2007
Formats:txt html json
Obsoletes:RFC 1991, RFC 2440
Updated by:RFC 5581
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4880
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions.It does, however, discuss implementation issues necessary to avoid security flaws.

OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP.

 
RFC 4884 Extended ICMP to Support Multi-Part Messages
 
Authors:R. Bonica, D. Gan, D. Tappan, C. Pignataro.
Date:April 2007
Formats:txt html json
Updates:RFC 0792, RFC 4443
Updated by:RFC 8335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4884
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.

Multi-part messages are supported by an ICMP extension structure.The extension structure is situated at the end of the ICMP message.It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an"original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length.Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the"original datagram" field.

The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.

This memo updates RFC 792 and RFC 4443.

 
RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
 
Authors:L. Dusseault, Ed..
Date:June 2007
Formats:txt html json
Obsoletes:RFC 2518
Updated by:RFC 5689
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4918
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.

 
RFC 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks
 
Authors:G. Swallow, S. Bryant, L. Andersson.
Date:June 2007
Formats:txt html json
Updated by:RFC 7274
Also:BCP 0128
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4928
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over anMPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.
 
RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
 
Authors:G. Montenegro, N. Kushalnagar, J. Hui, D. Culler.
Date:September 2007
Formats:txt json html
Updated by:RFC 6282, RFC 6775, RFC 8025, RFC 8066, RFC 8931
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4944
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE802.15.4 meshes.
 
RFC 4952 Overview and Framework for Internationalized Email
 
Authors:J. Klensin, Y. Ko.
Date:July 2007
Formats:txt html json
Obsoleted by:RFC 6530
Updated by:RFC 5336
Status:INFORMATIONAL
DOI:10.17487/RFC 4952
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.
 
RFC 4954 SMTP Service Extension for Authentication
 
Authors:R. Siemborski, Ed., A. Melnikov, Ed..
Date:July 2007
Formats:txt json html
Obsoletes:RFC 2554
Updates:RFC 3463
Updated by:RFC 5248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4954
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554.

 
RFC 4960 Stream Control Transmission Protocol
 
Authors:R. Stewart, Ed..
Date:September 2007
Formats:txt json html
Obsoletes:RFC 2960, RFC 3309
Obsoleted by:RFC 9260
Updated by:RFC 6096, RFC 6335, RFC 7053, RFC 8899
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4960
This document obsoletes RFC 2960 and RFC 3309. It describes theStream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

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

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

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

 
RFC 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
 
Authors:A. Allen, Ed., J. Holm, T. Hallin.
Date:September 2007
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 4964
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.
 
RFC 4969 IANA Registration for vCard Enumservice
 
Authors:A. Mayrhofer.
Date:August 2007
Formats:txt json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4969
This memo registers the Enumservice "vCard" using the URI schemes"http" and "https". This Enumservice is to be used to refer from anENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call.

 
RFC 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
 
Authors:D. Papadimitriou, A. Farrel.
Date:August 2007
Formats:txt json html
Updates:RFC 3473
Updated by:RFC 6001
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4974
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequentConnections may be made. In Generalized MPLS (GMPLS) suchConnections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol -Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logicalCall/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching.

 
RFC 4975 The Message Session Relay Protocol (MSRP)
 
Authors:B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed..
Date:September 2007
Formats:txt json html
Updated by:RFC 7977, RFC 8591, RFC 8873, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4975
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
 
RFC 4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP)
 
Authors:C. Jennings, R. Mahy, A. B. Roach.
Date:September 2007
Formats:txt html json
Updated by:RFC 7977, RFC 8553, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4976
Two separate models for conveying instant messages have been defined.Page-mode messages stand alone and are not part of a SessionInitiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session RelayProtocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.
 
RFC 4979 IANA Registration for Enumservice 'XMPP'
 
Authors:A. Mayrhofer.
Date:August 2007
Formats:txt json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4979
This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers(URIs) in the context of E.164 Number Mapping (ENUM).
 
RFC 4992 XML Pipelining with Chunks for the Internet Registry Information Service
 
Authors:A. Newton.
Date:August 2007
Formats:txt html json
Updates:RFC 3981
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4992
This document describes a simple TCP transfer protocol for theInternet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining.
 
RFC 5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)
 
Authors:G. Camarillo, G. Blanco.
Date:August 2007
Formats:txt json html
Updated by:RFC 8217
Status:INFORMATIONAL
DOI:10.17487/RFC 5002
This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS(IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destinationSIP URI of a particular SIP request.
 
RFC 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM)
 
Authors:M. Handley, I. Kouvelas, T. Speakman, L. Vicisano.
Date:October 2007
Formats:txt html json
Updated by:RFC 8736, RFC 9436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5015
This document discusses Bidirectional PIM (BIDIR-PIM), a variant ofPIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events.
 
RFC 5018 Connection Establishment in the Binary Floor Control Protocol (BFCP)
 
Authors:G. Camarillo.
Date:September 2007
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5018
This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS).
 
RFC 5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
 
Authors:A. Deacon, R. Hurst.
Date:September 2007
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5019
This specification defines a profile of the Online Certificate StatusProtocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure(PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing.
 
RFC 5023 The Atom Publishing Protocol
 
Authors:J. Gregorio, Ed., B. de hOra, Ed..
Date:October 2007
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5023
The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.
 
RFC 5024 ODETTE File Transfer Protocol 2.0
 
Authors:I. Friend.
Date:November 2007
Formats:txt html json
Obsoletes:RFC 2204
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5024
This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.

The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic MessageSyntax, and provides signed receipts for the acknowledgement of received files.

The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used withTCP/IP, X.25, and ISDN-based networks.

 
RFC 5026 Mobile IPv6 Bootstrapping in Split Scenario
 
Authors:G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed..
Date:October 2007
Formats:txt json html
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5026
A Mobile IPv6 node requires a Home Agent address, a home address, andIPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a MobileIPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the MobileNode. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the MobileNode's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario.
 
RFC 5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services
 
Authors:R. Mahy.
Date:October 2007
Formats:txt html json
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5028
This document registers a Telephone Number Mapping (ENUM) service forInstant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM.
 
RFC 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
 
Authors:H. Schulzrinne.
Date:January 2008
Formats:txt html json
Updated by:RFC 7163
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5031
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines.
 
RFC 5036 LDP Specification
 
Authors:L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed..
Date:October 2007
Formats:txt json html
Obsoletes:RFC 3036
Updated by:RFC 6720, RFC 6790, RFC 7358, RFC 7552
Status:DRAFT STANDARD
DOI:10.17487/RFC 5036
The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
 
RFC 5040 A Remote Direct Memory Access Protocol Specification
 
Authors:R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia.
Date:October 2007
Formats:txt json html
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5040
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol(ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation.
 
RFC 5041 Direct Data Placement over Reliable Transports
 
Authors:H. Shah, J. Pinkerton, R. Recio, P. Culley.
Date:October 2007
Formats:txt json html
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5041
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers.
 
RFC 5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security
 
Authors:J. Pinkerton, E. Deleganes.
Date:October 2007
Formats:txt html json
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5042
This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct MemoryAccess Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP orRDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from LocalPeers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege.
 
RFC 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
 
Authors:C. Bestler, Ed., R. Stewart, Ed..
Date:October 2007
Formats:txt html json
Updated by:RFC 6581, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5043
This document specifies an adaptation layer to provide a Lower LayerProtocol (LLP) service for Direct Data Placement (DDP) using theStream Control Transmission Protocol (SCTP).
 
RFC 5044 Marker PDU Aligned Framing for TCP Specification
 
Authors:P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier.
Date:October 2007
Formats:txt json html
Updated by:RFC 6581, RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5044
Marker PDU Aligned Framing (MPA) is designed to work as an"adaptation layer" between TCP and the Direct Data Placement protocol(DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level.
 
RFC 5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)
 
Authors:C. Bestler, Ed., L. Coene.
Date:October 2007
Formats:txt json html
Updated by:RFC 7146
Status:INFORMATIONAL
DOI:10.17487/RFC 5045
This document describes the applicability of Remote Direct MemoryAccess Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality.
 
RFC 5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)
 
Authors:M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler.
Date:October 2007
Formats:txt html json
Obsoleted by:RFC 7145
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5046
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite.
 
RFC 5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)
 
Authors:M. Chadalapaka, J. Hufferd, J. Satran, H. Shah.
Date:October 2007
Formats:txt html json
Updated by:RFC 7146
Status:INFORMATIONAL
DOI:10.17487/RFC 5047
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specificDatamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and theDatamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access(RDMA)-capable IP fabrics in the future comprising TCP, the StreamControl Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand.
 
RFC 5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications
 
Authors:M. Chadalapaka, Ed..
Date:October 2007
Formats:txt json html
Obsoleted by:RFC 7143
Updates:RFC 3720
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5048
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition inRFC 3720 to serve as a companion document for the iSCSI implementers.This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ.
 
RFC 5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
 
Authors:C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed..
Date:December 2007
Formats:txt json html
Updates:RFC 3486
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5049
This document describes some specifics that apply when SignalingCompression (SigComp) is applied to the Session Initiation Protocol(SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp overTCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP andSession Description Protocol (SDP) static dictionary.
 
RFC 5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication
 
Authors:D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin.
Date:November 2007
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5054
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol.
 
RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
 
Authors:N. Bhaskar, A. Gall, J. Lingard, S. Venaas.
Date:January 2008
Formats:txt pdf json html
Obsoletes:RFC 2362
Updates:RFC 4601
Updated by:RFC 8736, RFC 9436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5059
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol IndependentMulticast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure.
 
RFC 5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
 
Authors:E. Beili.
Date:November 2007
Formats:txt html json
Updated by:RFC 7124
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5066
This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.This document describes extensions to the Ethernet-like InterfacesMIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004(note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the InterfacesGroup MIB and the Inverted Stack Table MIB modules.
 
RFC 5068 Email Submission Operations: Access and Accountability Requirements
 
Authors:C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch.
Date:November 2007
Formats:txt json html
Updated by:RFC 8314
Also:BCP 0134
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5068
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet ServiceProviders. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.

Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document.

 
RFC 5070 The Incident Object Description Exchange Format
 
Authors:R. Danyliw, J. Meijer, Y. Demchenko.
Date:December 2007
Formats:txt json html
Obsoleted by:RFC 7970
Updated by:RFC 6685
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5070
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams(CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema.
 
RFC 5072 IP Version 6 over PPP
 
Authors:S. Varada, Ed., D. Haskins, E. Allen.
Date:September 2007
Formats:txt html json
Obsoletes:RFC 2472
Updated by:RFC 8064
Status:DRAFT STANDARD
DOI:10.17487/RFC 5072
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate AddressDetection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472.

 
RFC 5077 Transport Layer Security (TLS) Session Resumption without Server-Side State
 
Authors:J. Salowey, H. Zhou, P. Eronen, H. Tschofenig.
Date:January 2008
Formats:txt html json
Obsoletes:RFC 4507
Obsoleted by:RFC 8446
Updated by:RFC 8447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5077
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletesRFC 4507.
 
RFC 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
 
Authors:T. Nadeau, Ed., C. Pignataro, Ed..
Date:December 2007
Formats:txt json html
Updated by:RFC 5586
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5085
This document describes Virtual Circuit Connectivity Verification(VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs.
 
RFC 5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery
 
Authors:JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang.
Date:January 2008
Formats:txt json html
Updated by:RFC 9353
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5088
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within anOSPF area or within the entire OSPF routing domain.
 
RFC 5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery
 
Authors:JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang.
Date:January 2008
Formats:txt json html
Updated by:RFC 9353
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5089
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain.
 
RFC 5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems
 
Authors:X. Boyen, L. Martin.
Date:December 2007
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5091
This document describes the algorithms that implement Boneh-Franklin(BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-basedCryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document.
 
RFC 5092 IMAP URL Scheme
 
Authors:A. Melnikov, Ed., C. Newman.
Date:November 2007
Formats:txt html json
Obsoletes:RFC 2192
Updates:RFC 4467
Updated by:RFC 5593
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5092
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.

This document obsoletes RFC 2192. It also updates RFC 4467.

 
RFC 5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)
 
Authors:G. Beacham, S. Kumar, S. Channabasappa.
Date:February 2008
Formats:txt json html
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5098
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices.
 
RFC 5102 Information Model for IP Flow Information Export
 
Authors:J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer.
Date:January 2008
Formats:txt html json
Obsoleted by:RFC 7012
Updated by:RFC 6313
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5102
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.
 
RFC 5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
 
Authors:S. Wenger, U. Chandra, M. Westerlund, B. Burman.
Date:February 2008
Formats:txt json html
Updated by:RFC 7728, RFC 8082
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5104
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.

The extensions discussed are messages related to the ITU-T Rec. H.271Video Back Channel, Full Intra Request, Temporary Maximum MediaStream Bit Rate, and Temporal-Spatial Trade-off.

 
RFC 5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks
 
Authors:B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli.
Date:February 2008
Formats:txt json html
Updated by:RFC 8064
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5121
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MANCSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes theIEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers.
 
RFC 5129 Explicit Congestion Marking in MPLS
 
Authors:B. Davie, B. Briscoe, J. Tay.
Date:January 2008
Formats:txt json html
Updates:RFC 3032
Updated by:RFC 5462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5129
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in anMPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses.
 
RFC 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
 
Authors:B. Laurie, G. Sisson, R. Arends, D. Blacka.
Date:March 2008
Formats:txt html json
Updated by:RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5155
The Domain Name System Security (DNSSEC) Extensions introduced theNSEC resource record (RR) for authenticated denial of existence.This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.
 
RFC 5158 6to4 Reverse DNS Delegation Specification
 
Authors:G. Huston.
Date:March 2008
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5158
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested6to4 delegation address block.
 
RFC 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
 
Authors:M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba.
Date:January 2008
Formats:txt json html
Obsoletes:RFC 3576
Updated by:RFC 8559
Status:INFORMATIONAL
DOI:10.17487/RFC 5176
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
 
RFC 5177 Network Mobility (NEMO) Extensions for Mobile IPv4
 
Authors:K. Leung, G. Dommety, V. Narayanan, A. Petrescu.
Date:April 2008
Formats:txt json html
Updated by:RFC 6626
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5177
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the MobileRouter and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks.

 
RFC 5191 Protocol for Carrying Authentication for Network Access (PANA)
 
Authors:D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin.
Date:May 2008
Formats:txt html json
Updated by:RFC 5872
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5191
This document defines the Protocol for Carrying Authentication forNetwork Access (PANA), a network-layer transport for ExtensibleAuthentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is aUDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator.
 
RFC 5201 Host Identity Protocol
 
Authors:R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson.
Date:April 2008
Formats:txt html json
Obsoleted by:RFC 7401
Updated by:RFC 6253
Status:EXPERIMENTAL
DOI:10.17487/RFC 5201
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.
 
RFC 5213 Proxy Mobile IPv6
 
Authors:S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil.
Date:August 2008
Formats:txt json html
Updated by:RFC 6543, RFC 7864
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5213
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6.
 
RFC 5216 The EAP-TLS Authentication Protocol
 
Authors:D. Simon, B. Aboba, R. Hurst.
Date:March 2008
Formats:txt json html
Obsoletes:RFC 2716
Updated by:RFC 8996, RFC 9190
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5216
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. TransportLayer Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.

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

 
RFC 5222 LoST: A Location-to-Service Translation Protocol
 
Authors:T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig.
Date:August 2008
Formats:txt json html
Updated by:RFC 6848, RFC 8917, RFC 9036
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5222
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
 
RFC 5228 Sieve: An Email Filtering Language
 
Authors:P. Guenther, Ed., T. Showalter, Ed..
Date:January 2008
Formats:txt html json
Obsoletes:RFC 3028
Updated by:RFC 5229, RFC 5429, RFC 6785, RFC 9042
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5228
This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.
 
RFC 5229 Sieve Email Filtering: Variables Extension
 
Authors:K. Homme.
Date:January 2008
Formats:txt html json
Updates:RFC 5228
Updated by:RFC 5173
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5229
In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined.
 
RFC 5230 Sieve Email Filtering: Vacation Extension
 
Authors:T. Showalter, N. Freed, Ed..
Date:January 2008
Formats:txt html json
Updated by:RFC 8580
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5230
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops.
 
RFC 5234 Augmented BNF for Syntax Specifications: ABNF
 
Authors:D. Crocker, Ed., P. Overell.
Date:January 2008
Formats:txt html json
Obsoletes:RFC 4234
Updated by:RFC 7405
Also:STD 0068
Status:INTERNET STANDARD
DOI:10.17487/RFC 5234
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.
 
RFC 5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
 
Authors:T. Phelan.
Date:May 2008
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5238
This document specifies the use of Datagram Transport Layer Security(DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service.
 
RFC 5243 OSPF Database Exchange Summary List Optimization
 
Authors:R. Ogier.
Date:May 2008
Formats:txt html json
Updated by:RFC 9454
Status:INFORMATIONAL
DOI:10.17487/RFC 5243
This document describes a backward-compatible optimization for theDatabase Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reducesDatabase Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets.
 
RFC 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
 
Authors:J. Rosenberg.
Date:April 2010
Formats:txt json html
Obsoletes:RFC 4091, RFC 4092
Obsoleted by:RFC 8445, RFC 8839
Updated by:RFC 6336
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5245
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called InteractiveConnectivity Establishment (ICE). ICE makes use of the SessionTraversal Utilities for NAT (STUN) protocol and its extension,Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session InitiationProtocol (SIP).
 
RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
 
Authors:T. Dierks, E. Rescorla.
Date:August 2008
Formats:txt html json
Obsoletes:RFC 3268, RFC 4346, RFC 4366
Obsoleted by:RFC 8446
Updates:RFC 4492
Updated by:RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5246
This document specifies Version 1.2 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
 
RFC 5247 Extensible Authentication Protocol (EAP) Key Management Framework
 
Authors:B. Aboba, D. Simon, P. Eronen.
Date:August 2008
Formats:txt html json
Updates:RFC 3748
Updated by:RFC 8940
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5247
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated byEAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied.
 
RFC 5256 Internet Message Access Protocol - SORT and THREAD Extensions
 
Authors:M. Crispin, K. Murchison.
Date:June 2008
Formats:txt html json
Updated by:RFC 5957
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5256
This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views.
 
RFC 5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information
 
Authors:M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil.
Date:September 2008
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5263
By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the PresenceInformation Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed.
 
RFC 5267 Contexts for IMAP4
 
Authors:D. Cridland, C. King.
Date:July 2008
Formats:txt html json
Updated by:RFC 5465, RFC 9394
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5267
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes.
 
RFC 5272 Certificate Management over CMS (CMC)
 
Authors:J. Schaad, M. Myers.
Date:June 2008
Formats:txt html json
Obsoletes:RFC 2797
Updated by:RFC 6402
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5272
This document defines the base syntax for CMC, a CertificateManagement protocol using the Cryptographic Message Syntax (CMS).This protocol addresses two immediate needs within the InternetPublic Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key CryptographyStandard), and

2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.

CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.

 
RFC 5273 Certificate Management over CMS (CMC): Transport Protocols
 
Authors:J. Schaad, M. Myers.
Date:June 2008
Formats:txt html json
Updated by:RFC 6402
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5273
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic MessageSyntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.
 
RFC 5274 Certificate Management Messages over CMS (CMC): Compliance Requirements
 
Authors:J. Schaad, M. Myers.
Date:June 2008
Formats:txt json html
Updated by:RFC 6402
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5274
This document provides a set of compliance statements about the CMC(Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC.
 
RFC 5278 IANA Registration of Enumservices for Voice and Video Messaging
 
Authors:J. Livingood, D. Troshynski.
Date:July 2008
Formats:txt json html
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5278
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and"unifmsg". Each type also registers the subtypes "sip", "sips","http", and "https", as well as the subtype "tel" for the "voicemsg" type.
 
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
 
Authors:D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk.
Date:May 2008
Formats:txt json html
Obsoletes:RFC 3280, RFC 4325, RFC 4630
Updated by:RFC 6818, RFC 8398, RFC 8399, RFC 9549
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5280
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices.
 
RFC 5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
 
Authors:P. Funk, S. Blake-Wilson.
Date:August 2008
Formats:txt json html
Updated by:RFC 8996, RFC 9427
Status:INFORMATIONAL
DOI:10.17487/RFC 5281
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange.
 
RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates
 
Authors:A. Atlas, Ed., A. Zinin, Ed..
Date:September 2008
Formats:txt html json
Updated by:RFC 8518
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5286
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.This simple approach does not require any support from other routers.The extent to which this goal can be met by this specification is dependent on the topology of the network.
 
RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS
 
Authors:J. Salowey, A. Choudhury, D. McGrew.
Date:August 2008
Formats:txt json html
Updated by:RFC 9325
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5288
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms.
 
RFC 5301 Dynamic Hostname Exchange Mechanism for IS-IS
 
Authors:D. McPherson, N. Shen.
Date:October 2008
Formats:txt json html
Obsoletes:RFC 2763
Updated by:RFC 6232
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5301
RFC 2763 defined a simple and dynamic mechanism for routers runningIS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.

This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track.

 
RFC 5304 IS-IS Cryptographic Authentication
 
Authors:T. Li, R. Atkinson.
Date:October 2008
Formats:txt json html
Obsoletes:RFC 3567
Updates:RFC 1195
Updated by:RFC 6233, RFC 6232
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5304
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.

 
RFC 5305 IS-IS Extensions for Traffic Engineering
 
Authors:T. Li, H. Smit.
Date:October 2008
Formats:txt json html
Obsoletes:RFC 3784
Updated by:RFC 5307, RFC 8918
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5305
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
 
RFC 5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
 
Authors:K. Kompella, Ed., Y. Rekhter, Ed..
Date:October 2008
Formats:txt html json
Obsoletes:RFC 4205
Updates:RFC 5305
Updated by:RFC 6001, RFC 6002, RFC 7074
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5307
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS).
 
RFC 5308 Routing IPv6 with IS-IS
 
Authors:C. Hopps.
Date:October 2008
Formats:txt json html
Updated by:RFC 7775
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5308
This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface addressTLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 andOSI using a single intra-domain routing protocol.
 
RFC 5310 IS-IS Generic Cryptographic Authentication
 
Authors:M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto.
Date:February 2009
Formats:txt json html
Updated by:RFC 6233, RFC 6232
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5310
This document proposes an extension to Intermediate System toIntermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC5304. IS-IS is specified in International Standards Organization(ISO) 10589, with extensions to support Internet Protocol version 4(IPv4) described in RFC 1195.

Although this document has been written specifically for using theHashed Message Authentication Code (HMAC) construct along with theSecure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.

 
RFC 5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)
 
Authors:J. Hautakorpi, G. Camarillo.
Date:December 2008
Formats:txt json html
Updated by:RFC 8217
Status:INFORMATIONAL
DOI:10.17487/RFC 5318
This document specifies the Session Initiation Protocol (SIP)P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individualURIs that form such a URI list.
 
RFC 5321 Simple Mail Transfer Protocol
 
Authors:J. Klensin.
Date:October 2008
Formats:txt json html
Obsoletes:RFC 2821
Updates:RFC 1123
Updated by:RFC 7504
Status:DRAFT STANDARD
DOI:10.17487/RFC 5321
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments.
 
RFC 5322 Internet Message Format
 
Authors:P. Resnick, Ed..
Date:October 2008
Formats:txt html json
Obsoletes:RFC 2822
Updates:RFC 4021
Updated by:RFC 6854
Status:DRAFT STANDARD
DOI:10.17487/RFC 5322
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself supersededRequest For Comments (RFC) 822, "Standard for the Format of ARPAInternet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
 
RFC 5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)
 
Authors:A. Adolf, P. MacAvock.
Date:September 2008
Formats:txt json html
Updated by:RFC 7354, RFC 8553
Status:INFORMATIONAL
DOI:10.17487/RFC 5328
This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB.
 
RFC 5331 MPLS Upstream Label Assignment and Context-Specific Label Space
 
Authors:R. Aggarwal, Y. Rekhter, E. Rosen.
Date:August 2008
Formats:txt json html
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5331
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assignedMPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific LabelSpace".
 
RFC 5333 IANA Registration of Enumservices for Internet Calendaring
 
Authors:R. Mahy, B. Hoeneisen.
Date:October 2009
Formats:txt html json
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5333
This document registers Enumservices for Internet calendaring.Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (CalendaringExtensions to WebDAV).
 
RFC 5334 Ogg Media Types
 
Authors:I. Goncalves, S. Pfeiffer, C. Montgomery.
Date:September 2008
Formats:txt json html
Obsoletes:RFC 3534
Updated by:RFC 7845
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5334
This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534.
 
RFC 5340 OSPF for IPv6
 
Authors:R. Coltun, D. Ferguson, J. Moy, A. Lindem.
Date:July 2008
Formats:txt html json
Obsoletes:RFC 2740
Updated by:RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5340
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, Designated Router (DR) election, area support, ShortPath First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link StateAdvertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and EncapsulatingSecurity Payload (ESP).

Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.

 
RFC 5357 A Two-Way Active Measurement Protocol (TWAMP)
 
Authors:K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz.
Date:October 2008
Formats:txt json html
Updated by:RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5357
The One-way Active Measurement Protocol (OWAMP), specified in RFC4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active MeasurementProtocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances.
 
RFC 5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
 
Authors:J. Rosenberg, G. Camarillo, Ed., D. Willis.
Date:October 2008
Formats:txt html json
Updated by:RFC 8217
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5360
SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP.
 
RFC 5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
 
Authors:M. Garcia-Martin, G. Camarillo.
Date:October 2008
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5364
In certain types of multimedia communications, a Session InitiationProtocol (SIP) request is distributed to a group of SIP User Agents(UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems.
 
RFC 5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP)
 
Authors:G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil.
Date:October 2008
Formats:txt html json
Updated by:RFC 8262
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5368
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request.These extensions include the use of pointers to Uniform ResourceIdentifier (URI) lists in the Refer-To header field and the"multiple-refer" SIP option-tag.
 
RFC 5382 NAT Behavioral Requirements for TCP
 
Authors:S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh.
Date:October 2008
Formats:txt json html
Updated by:RFC 7857
Also:BCP 0142
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5382
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
 
RFC 5384 The Protocol Independent Multicast (PIM) Join Attribute Format
 
Authors:A. Boers, I. Wijnands, E. Rosen.
Date:November 2008
Formats:txt html json
Updated by:RFC 7887
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5384
A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format.
 
RFC 5389 Session Traversal Utilities for NAT (STUN)
 
Authors:J. Rosenberg, R. Mahy, P. Matthews, D. Wing.
Date:October 2008
Formats:txt html json
Obsoletes:RFC 3489
Obsoleted by:RFC 8489
Updated by:RFC 7350, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5389
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network AddressTranslator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489.

 
RFC 5403 RPCSEC_GSS Version 2
 
Authors:M. Eisler.
Date:February 2009
Formats:txt json html
Updates:RFC 2203
Updated by:RFC 7861
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5403
This document describes version 2 of the RPCSEC_GSS protocol.Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic SecurityServices Application Programming Interface (GSS-API).
 
RFC 5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0
 
Authors:A. Jerichow, Ed., L. Piron.
Date:January 2009
Formats:txt html json
Obsoletes:RFC 4909
Updated by:RFC 6309
Status:INFORMATIONAL
DOI:10.17487/RFC 5410
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload to transport the short-term key message(STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast(BCAST) group's Service and Content protection specification.
 
RFC 5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
 
Authors:P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed..
Date:March 2009
Formats:txt html json
Obsoletes:RFC 5414
Updated by:RFC 8553, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5415
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies.
 
RFC 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
 
Authors:A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangar.
Date:February 2009
Formats:txt html json
Obsoletes:RFC 4420
Updates:RFC 3209, RFC 3473
Updated by:RFC 6510
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5420
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs.

This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures.

 
RFC 5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
 
Authors:N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou.
Date:March 2009
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5422
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use ofEAP-FAST for dynamic provisioning.
 
RFC 5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices
 
Authors:S. Channabasappa, W. De Ketelaere, E. Nechamkin.
Date:April 2009
Formats:txt html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5428
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant MultimediaTerminal Adapter devices.
 
RFC 5435 Sieve Email Filtering: Extension for Notifications
 
Authors:A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin.
Date:January 2009
Formats:txt html json
Updated by:RFC 8580
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5435
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol(XMPP), or Global System for Mobile Communications (GSM) ShortMessage Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent.
 
RFC 5440 Path Computation Element (PCE) Communication Protocol (PCEP)
 
Authors:JP. Vasseur, Ed., JL. Le Roux, Ed..
Date:March 2009
Formats:txt json html
Updated by:RFC 7896, RFC 8253, RFC 8356, RFC 9488
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5440
This document specifies the Path Computation Element (PCE)Communication Protocol (PCEP) for communications between a PathComputation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
 
RFC 5443 LDP IGP Synchronization
 
Authors:M. Jork, A. Atlas, L. Fang.
Date:March 2009
Formats:txt html json
Updated by:RFC 6138
Status:INFORMATIONAL
DOI:10.17487/RFC 5443
In certain networks, there is dependency on the edge-to-edge LabelSwitched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS)Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol(IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border GatewayProtocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.
 
RFC 5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
 
Authors:T. Clausen, C. Dearlove, J. Dean, C. Adjih.
Date:February 2009
Formats:txt json html
Updated by:RFC 7631, RFC 8245
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5444
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols.
 
RFC 5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')
 
Authors:J. Arkko, V. Lehtovirta, P. Eronen.
Date:May 2009
Formats:txt json html
Updates:RFC 4187
Updated by:RFC 9048
Status:INFORMATIONAL
DOI:10.17487/RFC 5448
This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication ProtocolMethod for 3rd Generation Authentication and Key Agreement) method.The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd GenerationPartnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'.

 
RFC 5451 Message Header Field for Indicating Message Authentication Status
 
Authors:M. Kucherawy.
Date:April 2009
Formats:txt json html
Obsoleted by:RFC 7001
Updated by:RFC 6577
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5451
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.Any receiver-side software, such as mail filters or Mail User Agents(MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions.
 
RFC 5456 IAX: Inter-Asterisk eXchange Version 2
 
Authors:M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard.
Date:February 2010
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 5456
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for theAsterisk Private Branch Exchange (PBX) and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work aroundNAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services.

 
RFC 5460 DHCPv6 Bulk Leasequery
 
Authors:M. Stapp.
Date:February 2009
Formats:txt json html
Updated by:RFC 7653
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5460
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP.
 
RFC 5470 Architecture for IP Flow Information Export
 
Authors:G. Sadasivan, N. Brownlee, B. Claise, J. Quittek.
Date:March 2009
Formats:txt json html
Updated by:RFC 6183
Status:INFORMATIONAL
DOI:10.17487/RFC 5470
This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.
 
RFC 5480 Elliptic Curve Cryptography Subject Public Key Information
 
Authors:S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk.
Date:March 2009
Formats:txt json html
Updates:RFC 3279
Updated by:RFC 8813
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5480
This document specifies the syntax and semantics for the SubjectPublic Key Information field in certificates that support EllipticCurve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile", RFC 3279.
 
RFC 5485 Digital Signatures on Internet-Draft Documents
 
Authors:R. Housley.
Date:March 2009
Formats:txt json html
Updated by:RFC 8358
Status:INFORMATIONAL
DOI:10.17487/RFC 5485
This document specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
 
RFC 5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations
 
Authors:J. Winterbottom, M. Thomson, H. Tschofenig.
Date:March 2009
Formats:txt json html
Updates:RFC 4119
Updated by:RFC 7459
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5491
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented.In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing.
 
RFC 5492 Capabilities Advertisement with BGP-4
 
Authors:J. Scudder, R. Chandra.
Date:February 2009
Formats:txt html json
Obsoletes:RFC 3392
Updated by:RFC 8810
Status:DRAFT STANDARD
DOI:10.17487/RFC 5492
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392.

 
RFC 5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem
 
Authors:J. van Elburg.
Date:April 2009
Formats:txt html json
Updated by:RFC 8217, RFC 8498
Status:INFORMATIONAL
DOI:10.17487/RFC 5502
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd GenerationPartnership Project (3GPP) IMS (IP Multimedia Subsystem) between anS-CSCF (Serving Call Session Control Function) and an AS (ApplicationServer) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation.
 
RFC 5508 NAT Behavioral Requirements for ICMP
 
Authors:P. Srisuresh, B. Ford, S. Sivakumar, S. Guha.
Date:April 2009
Formats:txt json html
Updated by:RFC 7857
Also:BCP 0148
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5508
This document specifies the behavioral properties required of theNetwork Address Translator (NAT) devices in conjunction with theInternet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols.
 
RFC 5518 Vouch By Reference
 
Authors:P. Hoffman, J. Levine, A. Hathcock.
Date:April 2009
Formats:txt json html
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5518
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail.
 
RFC 5531 RPC: Remote Procedure Call Protocol Specification Version 2
 
Authors:R. Thurlow.
Date:May 2009
Formats:txt json html
Obsoletes:RFC 1831
Updated by:RFC 9289
Status:DRAFT STANDARD
DOI:10.17487/RFC 5531
This document describes the Open Network Computing (ONC) RemoteProcedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831.
 
RFC 5537 Netnews Architecture and Protocols
 
Authors:R. Allbery, Ed., C. Lindsey.
Date:November 2009
Formats:txt html json
Obsoletes:RFC 1036, RFC 1849
Updated by:RFC 8315
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5537
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.
 
RFC 5540 40 Years of RFCs
 
Authors:RFC Editor.
Date:April 2009
Formats:txt html json
Updated by:RFC 8700
Status:INFORMATIONAL
DOI:10.17487/RFC 5540
This RFC marks the 40th anniversary of the RFC document series.
 
RFC 5543 BGP Traffic Engineering Attribute
 
Authors:H. Ould-Brahim, D. Fedyk, Y. Rekhter.
Date:May 2009
Formats:txt json html
Updated by:RFC 7606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5543
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.

The scope and applicability of this attribute currently excludes its use for non-VPN reachability information.

 
RFC 5544 Syntax for Binding Documents with Time-Stamps
 
Authors:A. Santoni.
Date:February 2010
Formats:txt html json
Updated by:RFC 5955
Status:INFORMATIONAL
DOI:10.17487/RFC 5544
This document describes an envelope that can be used to bind a file(not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors.Additional types of temporal evidence are also allowed.

The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652.

 
RFC 5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar)
 
Authors:B. Desruisseaux, Ed..
Date:September 2009
Formats:txt html json
Obsoletes:RFC 2445
Updated by:RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5545
 
 
RFC 5546 iCalendar Transport-Independent Interoperability Protocol (iTIP)
 
Authors:C. Daboo, Ed..
Date:December 2009
Formats:txt json html
Obsoletes:RFC 2446
Updates:RFC 5545
Updated by:RFC 6638
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5546
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.

The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.

 
RFC 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers
 
Authors:H. Soliman, Ed..
Date:June 2009
Formats:txt html json
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5555
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where NetworkAddress Translation is present on the path between the mobile node and its home agent.
 
RFC 5560 A One-Way Packet Duplication Metric
 
Authors:H. Uijterwaal.
Date:May 2009
Formats:txt html json
Updated by:RFC 6248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5560
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams.

 
RFC 5568 Mobile IPv6 Fast Handovers
 
Authors:R. Koodli, Ed..
Date:July 2009
Formats:txt html json
Obsoletes:RFC 5268
Updated by:RFC 7411
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5568
Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures(namely, movement detection, new Care-of Address configuration, andBinding Update) is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.

This document updates the packet formats for the Handover Initiate(HI) and Handover Acknowledge (HAck) messages to the Mobility HeaderType.

 
RFC 5575 Dissemination of Flow Specification Rules
 
Authors:P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson.
Date:August 2009
Formats:txt html json
Obsoleted by:RFC 8955
Updated by:RFC 7674
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5575
This document defines a new Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate(distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements.

 
RFC 5580 Carrying Location Objects in RADIUS and Diameter
 
Authors:H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba.
Date:August 2009
Formats:txt html json
Updated by:RFC 8559
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5580
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service(RADIUS) and Diameter.

The distribution of location information is a privacy-sensitive task.Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document.

 
RFC 5586 MPLS Generic Associated Channel
 
Authors:M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed..
Date:June 2009
Formats:txt json html
Updates:RFC 3032, RFC 4385, RFC 5085
Updated by:RFC 6423, RFC 7026, RFC 7214, RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5586
This document generalizes the applicability of the pseudowire (PW)Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) andMPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.
 
RFC 5595 The Datagram Congestion Control Protocol (DCCP) Service Codes
 
Authors:G. Fairhurst.
Date:September 2009
Formats:txt html json
Updates:RFC 4340
Updated by:RFC 6335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5595
This document describes the usage of Service Codes by the DatagramCongestion Control Protocol, RFC 4340. It motivates the setting of aService Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC4340.
 
RFC 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding
 
Authors:R. Ogier, P. Spagnolo.
Date:August 2009
Formats:txt html json
Updated by:RFC 7038, RFC 9454
Status:EXPERIMENTAL
DOI:10.17487/RFC 5614
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANETDesignated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways.First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.
 
RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
 
Authors:E. Allman, J. Fenton, M. Delany, J. Levine.
Date:August 2009
Formats:txt json html
Updated by:RFC 8553
Status:HISTORIC
DOI:10.17487/RFC 5617
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record.
 
RFC 5621 Message Body Handling in the Session Initiation Protocol (SIP)
 
Authors:G. Camarillo.
Date:September 2009
Formats:txt html json
Updates:RFC 3204, RFC 3261, RFC 3459
Updated by:RFC 8262
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5621
This document specifies how message bodies are handled in SIP.Additionally, this document specifies SIP user agent support for MIME(Multipurpose Internet Mail Extensions) in message bodies.
 
RFC 5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
 
Authors:S. Floyd, E. Kohler.
Date:August 2009
Formats:txt json html
Updated by:RFC 6323, RFC 8311
Status:EXPERIMENTAL
DOI:10.17487/RFC 5622
This document specifies a profile for Congestion Control Identifier4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification(ECN), while minimizing abrupt rate changes.
 
RFC 5640 Load-Balancing for Mesh Softwires
 
Authors:C. Filsfils, P. Mohapatra, C. Pignataro.
Date:August 2009
Formats:txt json html
Updated by:RFC 9012
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5640
Payloads transported over a Softwire mesh service (as defined by BGPEncapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering theSoftwire can only be interpreted by the ingress and egress routers.Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two TunnelingProtocol - Version 3 (L2TPv3) over IP or Generic RoutingEncapsulation (GRE) encapsulation to what would be achieved without such encapsulation.
 
RFC 5644 IP Performance Metrics (IPPM): Spatial and Multicast
 
Authors:E. Stephan, L. Liang, A. Morton.
Date:October 2009
Formats:txt json html
Updated by:RFC 6248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5644
The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree).
 
RFC 5648 Multiple Care-of Addresses Registration
 
Authors:R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami.
Date:October 2009
Formats:txt json html
Updated by:RFC 6089
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5648
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (NetworkMobility) Basic Support protocol as well.
 
RFC 5652 Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:September 2009
Formats:txt html json
Obsoletes:RFC 3852
Updated by:RFC 8933
Also:STD 0070
Status:INTERNET STANDARD
DOI:10.17487/RFC 5652
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
 
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol
 
Authors:S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed..
Date:January 2010
Formats:txt json html
Obsoleted by:RFC 8881
Updated by:RFC 8178, RFC 8434
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5661
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, DirectoryDelegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior toNFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server.
 
RFC 5663 Parallel NFS (pNFS) Block/Volume Layout
 
Authors:D. Black, S. Fridella, J. Glasgow.
Date:January 2010
Formats:txt html json
Updated by:RFC 6688
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5663
Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage.
 
RFC 5679 Locating IEEE 802.21 Mobility Services Using DNS
 
Authors:G. Bajko.
Date:December 2009
Formats:txt json html
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5679
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-definedMobility Services. Such Mobility Services are used to assist aMobile Node (MN) supporting IEEE 802.21, in handover preparation(network discovery) and handover decision (network selection). The services addressed by this document are the Media IndependentHandover Services defined in IEEE 802.21.
 
RFC 5681 TCP Congestion Control
 
Authors:M. Allman, V. Paxson, E. Blanton.
Date:September 2009
Formats:txt json html
Obsoletes:RFC 2581
Updated by:RFC 9438
Status:DRAFT STANDARD
DOI:10.17487/RFC 5681
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581.
 
RFC 5701 IPv6 Address Specific BGP Extended Community Attribute
 
Authors:Y. Rekhter.
Date:November 2009
Formats:txt json html
Updated by:RFC 7153, RFC 7606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5701
Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support anIPv6 Address Specific Extended Community. The lack of an IPv6Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address SpecificExtended Community, that addresses this problem. The IPv6 AddressSpecific Extended Community is similar to the IPv4 Address SpecificExtended Community, except that it carries an IPv6 address rather than an IPv4 address.
 
RFC 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
 
Authors:J. Jansen.
Date:October 2009
Formats:txt html json
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5702
This document describes how to produce RSA/SHA-256 and RSA/SHA-512DNSKEY and RRSIG resource records for use in the Domain Name SystemSecurity Extensions (RFC 4033, RFC 4034, and RFC 4035).
 
RFC 5705 Keying Material Exporters for Transport Layer Security (TLS)
 
Authors:E. Rescorla.
Date:March 2010
Formats:txt json html
Updated by:RFC 8446, RFC 8447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5705
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that.
 
RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication
 
Authors:M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson.
Date:October 2009
Formats:txt json html
Updates:RFC 2328
Updated by:RFC 7474
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5709
This document describes how the National Institute of Standards andTechnology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328.
 
RFC 5722 Handling of Overlapping IPv6 Fragments
 
Authors:S. Krishnan.
Date:December 2009
Formats:txt html json
Updates:RFC 2460
Updated by:RFC 6946
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5722
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments.
 
RFC 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
 
Authors:J. Peterson, C. Jennings, R. Sparks.
Date:March 2010
Formats:txt html json
Obsoletes:RFC 3427
Updates:RFC 3265, RFC 3969
Updated by:RFC 7957
Also:BCP 0067
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5727
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC3427.
 
RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP
 
Authors:S. Hollenbeck.
Date:August 2009
Formats:txt json html
Obsoletes:RFC 4934
Updated by:RFC 8996
Also:STD 0069
Status:INTERNET STANDARD
DOI:10.17487/RFC 5734
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 4934.
 
RFC 5735 Special Use IPv4 Addresses
 
Authors:M. Cotton, L. Vegoda.
Date:January 2010
Formats:txt json html
Obsoletes:RFC 3330
Obsoleted by:RFC 6890
Updated by:RFC 6598
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 5735
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by theInternet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the RegionalInternet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional InternetRegistries. It also does not address allocations or assignments ofIPv6 addresses or autonomous system numbers.
 
RFC 5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
 
Authors:J. Ott, J. Chesterfield, E. Schooler.
Date:February 2010
Formats:txt html json
Updated by:RFC 6128
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5760
This document specifies an extension to the Real-time TransportControl Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism.
 
RFC 5761 Multiplexing RTP Data and Control Packets on a Single Port
 
Authors:C. Perkins, M. Westerlund.
Date:April 2010
Formats:txt html json
Updates:RFC 3550, RFC 3551
Updated by:RFC 8035, RFC 8858
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5761
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the SessionDescription Protocol (SDP) can be used to signal multiplexed sessions.
 
RFC 5762 RTP and the Datagram Congestion Control Protocol (DCCP)
 
Authors:C. Perkins.
Date:April 2010
Formats:txt json html
Updated by:RFC 6773
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5762
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion ControlProtocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP.
 
RFC 5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
 
Authors:J. Fischl, H. Tschofenig, E. Rescorla.
Date:May 2010
Formats:txt json html
Updated by:RFC 8842
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5763
This document specifies how to use the Session Initiation Protocol(SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.
 
RFC 5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
 
Authors:D. McGrew, E. Rescorla.
Date:May 2010
Formats:txt html json
Updated by:RFC 7983, RFC 9443
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5764
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTPControl Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.
 
RFC 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
 
Authors:R. Mahy, P. Matthews, J. Rosenberg.
Date:April 2010
Formats:txt json html
Obsoleted by:RFC 8656
Updated by:RFC 8155, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5766
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts(peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (TraversalUsing Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.

The TURN protocol was designed to be used as part of the ICE(Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE.

 
RFC 5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
 
Authors:D. MacDonald, B. Lowekamp.
Date:May 2010
Formats:txt html json
Updated by:RFC 8553
Status:EXPERIMENTAL
DOI:10.17487/RFC 5780
This specification defines an experimental usage of the SessionTraversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.
 
RFC 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions
 
Authors:R. Aggarwal, K. Kompella.
Date:March 2010
Formats:txt json html
Updates:RFC 3630
Updated by:RFC 6827, RFC 8687
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5786
OSPF Traffic Engineering (TE) extensions are used to advertise TELink State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute MultiprotocolLabel Switching (MPLS) Traffic Engineered Label Switched Paths (TELSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses.

 
RFC 5788 IMAP4 Keyword Registry
 
Authors:A. Melnikov, D. Cridland.
Date:March 2010
Formats:txt html json
Updated by:RFC 8621
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5788
The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients.
 
RFC 5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
 
Authors:S. Josefsson, N. Williams.
Date:July 2010
Formats:txt json html
Updated by:RFC 9266
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5801
This document describes how to use a Generic Security ServiceApplication Program Interface (GSS-API) mechanism in the SimpleAuthentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported.
 
RFC 5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
 
Authors:C. Newman, A. Menon-Sen, A. Melnikov, N. Williams.
Date:July 2010
Formats:txt html json
Updated by:RFC 7677, RFC 9266
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5802
The secure authentication mechanism most widely deployed and used byInternet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS).There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.

This specification describes a family of Simple Authentication andSecurity Layer (SASL; RFC 4422) authentication mechanisms called theSalted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards.

 
RFC 5804 A Protocol for Remotely Managing Sieve Scripts
 
Authors:A. Melnikov, Ed., T. Martin.
Date:July 2010
Formats:txt json html
Updated by:RFC 7817, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5804
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts.
 
RFC 5810 Forwarding and Control Element Separation (ForCES) Protocol Specification
 
Authors:A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern.
Date:March 2010
Formats:txt json html
Updated by:RFC 7121, RFC 7391
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5810
This document specifies the Forwarding and Control Element Separation(ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in aForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654.Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).
 
RFC 5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model
 
Authors:J. Halpern, J. Hadi Salim.
Date:March 2010
Formats:txt html json
Updated by:RFC 7408
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5812
This document defines the forwarding element (FE) model used in theForwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654.
 
RFC 5818 Data Channel Status Confirmation Extensions for the Link Management Protocol
 
Authors:D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia.
Date:April 2010
Formats:txt json html
Updated by:RFC 6898
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5818
This document defines simple additions to the Link ManagementProtocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-SwitchingRouters (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found.As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
 
RFC 5820 Extensions to OSPF to Support Mobile Ad Hoc Networking
 
Authors:A. Roy, Ed., M. Chandra, Ed..
Date:March 2010
Formats:txt json html
Updated by:RFC 7137
Status:EXPERIMENTAL
DOI:10.17487/RFC 5820
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-OverlappingRelay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs.
 
RFC 5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms
 
Authors:V. Dolmatov, Ed..
Date:March 2010
Formats:txt json html
Updated by:RFC 8891
Status:INFORMATIONAL
DOI:10.17487/RFC 5830
This document is intended to be a source of information about theRussian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication.
 
RFC 5831 GOST R 34.11-94: Hash Function Algorithm
 
Authors:V. Dolmatov, Ed..
Date:March 2010
Formats:txt json html
Updated by:RFC 6986
Status:INFORMATIONAL
DOI:10.17487/RFC 5831
This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation.
 
RFC 5832 GOST R 34.10-2001: Digital Signature Algorithm
 
Authors:V. Dolmatov, Ed..
Date:March 2010
Formats:txt html json
Updated by:RFC 7091
Status:INFORMATIONAL
DOI:10.17487/RFC 5832
This document is intended to be a source of information about theRussian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (calledGOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.
 
RFC 5838 Support of Address Families in OSPFv3
 
Authors:A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal.
Date:April 2010
Formats:txt json html
Updated by:RFC 6969, RFC 7949, RFC 8362, RFC 9454
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5838
This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions toOSPFv3 for supporting multiple AFs.
 
RFC 5864 DNS SRV Resource Records for AFS
 
Authors:R. Allbery.
Date:April 2010
Formats:txt html json
Updates:RFC 1183
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5864
This document specifies how to use DNS (Domain Name Service) SRV RRs(Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility.
 
RFC 5878 Transport Layer Security (TLS) Authorization Extensions
 
Authors:M. Brown, R. Housley.
Date:May 2010
Formats:txt html json
Updates:RFC 5246
Updated by:RFC 8447, RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 5878
This document specifies authorization extensions to the TransportLayer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language(SAML) assertions, is exchanged in the supplemental data handshake message.
 
RFC 5880 Bidirectional Forwarding Detection (BFD)
 
Authors:D. Katz, D. Ward.
Date:June 2010
Formats:txt html json
Updated by:RFC 7419, RFC 7880, RFC 8562
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5880
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols.
 
RFC 5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
 
Authors:R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow.
Date:June 2010
Formats:txt html json
Updates:RFC 1122
Updated by:RFC 7726
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5884
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label SwitchedPath (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination ofLSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability ofBFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment.
 
RFC 5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
 
Authors:T. Nadeau, Ed., C. Pignataro, Ed..
Date:June 2010
Formats:txt html json
Updated by:RFC 6478, RFC 7885
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5885
This document describes Connectivity Verification (CV) Types usingBidirectional Forwarding Detection (BFD) with Virtual CircuitConnectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel.
 
RFC 5888 The Session Description Protocol (SDP) Grouping Framework
 
Authors:G. Camarillo, H. Schulzrinne.
Date:June 2010
Formats:txt html json
Obsoletes:RFC 3388
Updated by:RFC 8843, RFC 9143
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5888
In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388.
 
RFC 5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
 
Authors:P. Faltstrom, Ed..
Date:August 2010
Formats:txt json html
Updated by:RFC 8753
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5892
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).

It is part of the specification of Internationalizing Domain Names inApplications 2008 (IDNA2008).

 
RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification
 
Authors:D. Mills, J. Martin, Ed., J. Burbank, W. Kasch.
Date:June 2010
Formats:txt html json
Obsoletes:RFC 1305, RFC 4330
Updated by:RFC 7822, RFC 8573, RFC 9109
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5905
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.NTPv4 includes a modified protocol header to accommodate the InternetProtocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.
 
RFC 5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
 
Authors:P. Hoffman, J. Schaad.
Date:June 2010
Formats:txt html json
Updated by:RFC 6268
Status:INFORMATIONAL
DOI:10.17487/RFC 5911
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates thoseASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.
 
RFC 5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
 
Authors:P. Hoffman, J. Schaad.
Date:June 2010
Formats:txt json html
Updated by:RFC 6960, RFC 9480
Status:INFORMATIONAL
DOI:10.17487/RFC 5912
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The currentASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.
 
RFC 5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
 
Authors:R. Asati, I. Minei, B. Thomas.
Date:August 2010
Formats:txt html json
Updated by:RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5918
The Label Distribution Protocol (LDP) specification for the WildcardForward Equivalence Class (FEC) element has several limitations.This document addresses those limitations by defining a TypedWildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility.
 
RFC 5921 A Framework for MPLS in Transport Networks
 
Authors:M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger.
Date:July 2010
Formats:txt html json
Updated by:RFC 6215, RFC 7274
Status:INFORMATIONAL
DOI:10.17487/RFC 5921
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance(OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of theMPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism
 
Authors:M. Petit-Huguenin.
Date:August 2010
Formats:txt html json
Updated by:RFC 7350, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5928
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a TraversalUsing Relays around NAT (TURN) allocation.
 
RFC 5929 Channel Bindings for TLS
 
Authors:J. Altman, N. Williams, L. Zhu.
Date:July 2010
Formats:txt html json
Updated by:RFC 9266
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5929
This document defines three channel binding types for Transport LayerSecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding).

Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry.

 
RFC 5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password
 
Authors:D. Harkins, G. Zorn.
Date:August 2010
Formats:txt html json
Updated by:RFC 8146
Status:INFORMATIONAL
DOI:10.17487/RFC 5931
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.
 
RFC 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
 
Authors:V. Dolmatov, Ed., A. Chuprina, I. Ustinov.
Date:July 2010
Formats:txt json html
Updated by:RFC 6944
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5933
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the DomainName System Security Extensions (DNSSEC).
 
RFC 5936 DNS Zone Transfer Protocol (AXFR)
 
Authors:E. Lewis, A. Hoenes, Ed..
Date:June 2010
Formats:txt json html
Updates:RFC 1034, RFC 1035
Updated by:RFC 9103
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5936
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.

The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism.

 
RFC 5939 Session Description Protocol (SDP) Capability Negotiation
 
Authors:F. Andreasen.
Date:September 2010
Formats:txt html json
Updated by:RFC 6871
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5939
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.

The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.

The document defines a general SDP Capability Negotiation framework.It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents.

 
RFC 5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
 
Authors:W. Hardaker.
Date:August 2010
Formats:txt html json
Obsoleted by:RFC 6353
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5953
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.

 
RFC 5959 Algorithms for Asymmetric Key Package Content Type
 
Authors:S. Turner.
Date:August 2010
Formats:txt json html
Updated by:RFC 6162
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5959
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData,EnvelopedData, EncryptedData, AuthenticatedData, andAuthEnvelopedData.
 
RFC 5960 MPLS Transport Profile Data Plane Architecture
 
Authors:D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed..
Date:August 2010
Formats:txt json html
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5960
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network.

 
RFC 5961 Improving TCP's Robustness to Blind In-Window Attacks
 
Authors:A. Ramaiah, R. Stewart, M. Dalal.
Date:August 2010
Formats:txt json html
Updated by:RFC 9293
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5961
TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 orBorder Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.

Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed.Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack.

 
RFC 5965 An Extensible Format for Email Feedback Reports
 
Authors:Y. Shafranovich, J. Levine, M. Kucherawy.
Date:August 2010
Formats:txt json html
Updated by:RFC 6650
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5965
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used inInternet email.
 
RFC 5985 HTTP-Enabled Location Delivery (HELD)
 
Authors:M. Barnes, Ed..
Date:September 2010
Formats:txt json html
Updated by:RFC 7840
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5985
This document defines a Layer 7 Location Configuration Protocol (L7LCP) and describes the use of HTTP and HTTP/TLS as transports for theL7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer.
 
RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2)
 
Authors:C. Kaufman, P. Hoffman, Y. Nir, P. Eronen.
Date:September 2010
Formats:txt html json
Obsoletes:RFC 4306, RFC 4718
Obsoleted by:RFC 7296
Updated by:RFC 5998, RFC 6989
Status:PROPOSED STANDARD
DOI:10.17487/RFC 5996
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations(SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718.
 
RFC 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
 
Authors:J. Salowey, T. Petch, R. Gerhards, H. Feng.
Date:October 2010
Formats:txt html json
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6012
This document describes the transport of syslog messages over theDatagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired.
 
RFC 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC
 
Authors:P. Hoffman.
Date:November 2010
Formats:txt json html
Updates:RFC 4033, RFC 4034, RFC 4035
Updated by:RFC 9157
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6014
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required forDNSSEC implementations.
 
RFC 6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
 
Authors:S. Turner.
Date:December 2010
Formats:txt html json
Updated by:RFC 6161
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6033
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, andAuthEnvelopedData.
 
RFC 6042 Transport Layer Security (TLS) Authorization Using KeyNote
 
Authors:A. Keromytis.
Date:October 2010
Formats:txt json html
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 6042
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security(TLS) Handshake Protocol, according to guidelines in RFC 5878.Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message.
 
RFC 6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
 
Authors:J. Mattsson, T. Tian.
Date:March 2011
Formats:txt json html
Updated by:RFC 6309
Status:INFORMATIONAL
DOI:10.17487/RFC 6043
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing.Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.
 
RFC 6049 Spatial Composition of Metrics
 
Authors:A. Morton, E. Stephan.
Date:January 2011
Formats:txt html json
Updated by:RFC 6248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6049
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow.
 
RFC 6053 Implementation Report for Forwarding and Control Element Separation (ForCES)
 
Authors:E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim.
Date:November 2010
Formats:txt json html
Updated by:RFC 6984
Status:INFORMATIONAL
DOI:10.17487/RFC 6053
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.

This document is an implementation report for the ForCES Protocol,Model, and the Stream Control Transmission Protocol-based TransportMapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations.

 
RFC 6066 Transport Layer Security (TLS) Extensions: Extension Definitions
 
Authors:D. Eastlake 3rd.
Date:January 2011
Formats:txt json html
Obsoletes:RFC 4366
Updated by:RFC 8446, RFC 8449, RFC 9325
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6066
This document provides specifications for existing TLS extensions.It is a companion document for RFC 5246, "The Transport LayerSecurity (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.
 
RFC 6073 Segmented Pseudowire
 
Authors:L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui.
Date:January 2011
Formats:txt json html
Updated by:RFC 6723, RFC 7267
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6073
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload.
 
RFC 6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
 
Authors:M. Tuexen, R. Seggelmann, E. Rescorla.
Date:January 2011
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6083
This document describes the usage of the Datagram Transport LayerSecurity (DTLS) protocol over the Stream Control TransmissionProtocol (SCTP).

DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions.

 
RFC 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)
 
Authors:X. Fu, C. Dickmann, J. Crowcroft.
Date:January 2011
Formats:txt html json
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 6084
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over theStream Control Transmission Protocol (SCTP) and Datagram TransportLayer Security (DTLS).
 
RFC 6105 IPv6 Router Advertisement Guard
 
Authors:E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi.
Date:February 2011
Formats:txt html json
Updated by:RFC 7113
Status:INFORMATIONAL
DOI:10.17487/RFC 6105
Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status.
 
RFC 6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content
 
Authors:L. Lhotka, Ed..
Date:February 2011
Formats:txt html json
Updated by:RFC 7952
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6110
This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG),Schematron, and Schematron and Document Schema Renaming Language(DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.Procedures for schema-based validation of such documents are also discussed.
 
RFC 6120 Extensible Messaging and Presence Protocol (XMPP): Core
 
Authors:P. Saint-Andre.
Date:March 2011
Formats:txt html json
Obsoletes:RFC 3920
Updated by:RFC 7590, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6120
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document definesXMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920.
 
RFC 6126 The Babel Routing Protocol
 
Authors:J. Chroboczek.
Date:April 2011
Formats:txt json html
Obsoleted by:RFC 8966
Updated by:RFC 7298, RFC 7557
Status:EXPERIMENTAL
DOI:10.17487/RFC 6126
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
 
RFC 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
 
Authors:T. Clausen, C. Dearlove, J. Dean.
Date:April 2011
Formats:txt html json
Updated by:RFC 7183, RFC 7188, RFC 7466
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6130
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
 
RFC 6145 IP/ICMP Translation Algorithm
 
Authors:X. Li, C. Bao, F. Baker.
Date:April 2011
Formats:txt json html
Obsoletes:RFC 2765
Obsoleted by:RFC 7915
Updated by:RFC 6791, RFC 7757
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6145
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 2765.
 
RFC 6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
 
Authors:J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes.
Date:March 2011
Formats:txt json html
Updated by:RFC 6915
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6155
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.

Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.

This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted.

 
RFC 6158 RADIUS Design Guidelines
 
Authors:A. DeKok, Ed., G. Weber.
Date:March 2011
Formats:txt json html
Updated by:RFC 6929, RFC 8044
Also:BCP 0158
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6158
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs).
 
RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links
 
Authors:M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten.
Date:April 2011
Formats:txt json html
Updated by:RFC 6547
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6164
On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links.
 
RFC 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0
 
Authors:S. Turner, T. Polk.
Date:March 2011
Formats:txt html json
Updates:RFC 2246, RFC 4346, RFC 5246
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6176
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport LayerSecurity (TLS).
 
RFC 6186 Use of SRV Records for Locating Email Submission/Access Services
 
Authors:C. Daboo.
Date:March 2011
Formats:txt html json
Updates:RFC 1939, RFC 3501
Updated by:RFC 8314, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6186
This specification describes how SRV records can be used to locate email services.
 
RFC 6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
 
Authors:T. Otani, Ed., D. Li, Ed..
Date:March 2011
Formats:txt json html
Updates:RFC 3471
Updated by:RFC 7699, RFC 8359
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6205
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.

Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.Global wavelength semantics are not considered.

In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the DenseWavelength Division Multiplexing (DWDM) and Coarse WavelengthDivision Multiplexing (CWDM) grids defined by the InternationalTelecommunication Union Telecommunication Standardization Sector.The label format defined in this document can be used in GMPLS signaling and routing protocols.

 
RFC 6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework
 
Authors:S. McGlashan, T. Melanchuk, C. Boulton.
Date:May 2011
Formats:txt json html
Updated by:RFC 6623
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6231
This document defines a Media Control Channel Framework Package forInteractive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs.
 
RFC 6232 Purge Originator Identification TLV for IS-IS
 
Authors:F. Wei, Y. Qin, Z. Li, T. Li, J. Dong.
Date:May 2011
Formats:txt html json
Updates:RFC 5301, RFC 5304, RFC 5310
Updated by:RFC 8918
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6232
At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge.This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normalLink State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.

This document updates RFC 5301, RFC 5304, and RFC 5310.

 
RFC 6241 Network Configuration Protocol (NETCONF)
 
Authors:R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed..
Date:June 2011
Formats:txt html json
Obsoletes:RFC 4741
Updated by:RFC 7803, RFC 8526
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6241
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletesRFC 4741.
 
RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
 
Authors:J. Hui, Ed., P. Thubert.
Date:September 2011
Formats:txt json html
Updates:RFC 4944
Updated by:RFC 8066
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6282
This document updates RFC 4944, "Transmission of IPv6 Packets overIEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power WirelessPersonal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope.This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.
 
RFC 6292 Requirements for a Working Group Charter Tool
 
Authors:P. Hoffman.
Date:June 2011
Formats:txt json html
Updated by:RFC 6433
Status:INFORMATIONAL
DOI:10.17487/RFC 6292
The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool.
 
RFC 6320 Protocol for Access Node Control Mechanism in Broadband Networks
 
Authors:S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed..
Date:October 2011
Formats:txt html json
Updated by:RFC 7256
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6320
This document describes the Access Node Control Protocol (ANCP).ANCP operates between a Network Access Server (NAS) and an AccessNode (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the baseANCP protocol, this document specifies capabilities for DigitalSubscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3(GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it.

 
RFC 6321 xCal: The XML Format for iCalendar
 
Authors:C. Daboo, M. Douglass, S. Lees.
Date:August 2011
Formats:txt html json
Updated by:RFC 6868, RFC 7529
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6321
This specification defines "xCal", an XML format for iCalendar data.
 
RFC 6325 Routing Bridges (RBridges): Base Protocol Specification
 
Authors:R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani.
Date:July 2011
Formats:txt html json
Updated by:RFC 6327, RFC 6439, RFC 7172, RFC 7177, RFC 7357, RFC 7179, RFC 7180, RFC 7455, RFC 7780, RFC 7783, RFC 8139, RFC 8249, RFC 8361, RFC 8377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6325
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges(rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges.

 
RFC 6327 Routing Bridges (RBridges): Adjacency
 
Authors:D. Eastlake 3rd, R. Perlman, A. Ghanwani, D. Dutt, V. Manral.
Date:July 2011
Formats:txt json html
Obsoleted by:RFC 7177
Updates:RFC 6325
Updated by:RFC 7180
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6327
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU(Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.

 
RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
 
Authors:A. Durand, R. Droms, J. Woodyatt, Y. Lee.
Date:August 2011
Formats:txt json html
Updated by:RFC 7335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6333
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT).
 
RFC 6347 Datagram Transport Layer Security Version 1.2
 
Authors:E. Rescorla, N. Modadugu.
Date:January 2012
Formats:txt html json
Obsoletes:RFC 4347
Obsoleted by:RFC 9147
Updated by:RFC 7507, RFC 7905, RFC 8996, RFC 9146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6347
This document specifies version 1.2 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updatesDTLS 1.0 to work with TLS version 1.2.
 
RFC 6350 vCard Format Specification
 
Authors:S. Perreault.
Date:August 2011
Formats:txt json html
Obsoletes:RFC 2425, RFC 2426, RFC 4770
Updates:RFC 2739
Updated by:RFC 6868
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6350
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.
 
RFC 6351 xCard: vCard XML Representation
 
Authors:S. Perreault.
Date:August 2011
Formats:txt json html
Updated by:RFC 6868
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6351
This document defines the XML schema of the vCard data format.
 
RFC 6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
 
Authors:C. Daboo.
Date:August 2011
Formats:txt html json
Updated by:RFC 6764
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6352
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format.
 
RFC 6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
 
Authors:W. Hardaker.
Date:July 2011
Formats:txt html json
Obsoletes:RFC 5953
Updated by:RFC 8996, RFC 9456
Also:STD 0078
Status:INTERNET STANDARD
DOI:10.17487/RFC 6353
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of anSNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.

 
RFC 6363 Forward Error Correction (FEC) Framework
 
Authors:M. Watson, A. Begen, V. Roca.
Date:October 2011
Formats:txt html json
Updated by:RFC 8680
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6363
This document describes a framework for using Forward ErrorCorrection (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content DeliveryProtocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.
 
RFC 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)
 
Authors:S. Kanno, M. Kanda.
Date:September 2011
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 6367
This document specifies forty-two cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.
 
RFC 6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
 
Authors:P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata.
Date:September 2011
Formats:txt json html
Updated by:RFC 7606, RFC 9494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6368
This document defines protocol extensions and procedures for BGPProvider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned.
 
RFC 6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
 
Authors:I. Busi, Ed., D. Allan, Ed..
Date:September 2011
Formats:txt json html
Updated by:RFC 6435
Status:INFORMATIONAL
DOI:10.17487/RFC 6371
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS TrafficEngineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set ofOperations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 6374 Packet Loss and Delay Measurement for MPLS Networks
 
Authors:D. Frost, S. Bryant.
Date:September 2011
Formats:txt json html
Updated by:RFC 7214
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6374
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
 
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
 
Authors:D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed..
Date:September 2011
Formats:txt html json
Obsoletes:RFC 4871, RFC 5672
Updated by:RFC 8301, RFC 8463, RFC 8553, RFC 8616
Also:STD 0076
Status:INTERNET STANDARD
DOI:10.17487/RFC 6376
DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672.

 
RFC 6378 MPLS Transport Profile (MPLS-TP) Linear Protection
 
Authors:Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed..
Date:October 2011
Formats:txt json html
Updated by:RFC 7214, RFC 7271, RFC 7324
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6378
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationsStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TPSurvivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection StateCoordination for linear protection, as described in that document.

 
RFC 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
 
Authors:IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas.
Date:November 2011
Formats:txt json html
Updated by:RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6388
This document describes extensions to the Label Distribution Protocol(LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.These extensions are also referred to as multipoint LDP. MultipointLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks(L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document.
 
RFC 6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
 
Authors:S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante.
Date:November 2011
Formats:txt json html
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6391
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal CostMultiple Paths (ECMPs) that exist in the packet switched network.Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires.The mechanism uses an additional label in the MPLS label stack.

 
RFC 6409 Message Submission for Mail
 
Authors:R. Gellens, J. Klensin.
Date:November 2011
Formats:txt json html
Obsoletes:RFC 4409
Updated by:RFC 8314
Also:STD 0072
Status:INTERNET STANDARD
DOI:10.17487/RFC 6409
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.

 
RFC 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
 
Authors:N. Bahadur, K. Kompella, G. Swallow.
Date:November 2011
Formats:txt json html
Obsoleted by:RFC 8029
Updates:RFC 4379
Updated by:RFC 7537
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6424
This document describes methods for performing LSP ping (specified inRFC 4379) traceroute over MPLS tunnels and for traceroute of stitchedMPLS Label Switched Paths (LSPs). The techniques outlined in RFC4379 are insufficient to perform traceroute Forwarding EquivalencyClass (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a newTLV that, along with other procedures outlined in this document, can be used to trace such LSPs.
 
RFC 6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM)
 
Authors:G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward.
Date:November 2011
Formats:txt html json
Updated by:RFC 7214
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6427
This document specifies Operations, Administration, and Maintenance(OAM) messages to indicate service disruptive conditions for MPLS- based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions.
 
RFC 6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
 
Authors:D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed..
Date:November 2011
Formats:txt json html
Updated by:RFC 7214
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6428
Continuity Check, Proactive Connectivity Verification, and RemoteDefect Indication functionalities are required for MPLS TransportProfile (MPLS-TP) Operations, Administration, and Maintenance (OAM).

Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments ContinuityCheck in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, orSection.

This document specifies specific extensions to BidirectionalForwarding Detection (BFD) and methods for proactive ContinuityCheck, Continuity Verification, and Remote Defect Indication forMPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo.

 
RFC 6439 Routing Bridges (RBridges): Appointed Forwarders
 
Authors:R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu.
Date:November 2011
Formats:txt json html
Obsoleted by:RFC 8139
Updates:RFC 6325
Updated by:RFC 7180
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6439
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to IntermediateSystem) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multipleRBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called"Appointed Forwarders", with the intent that native traffic in eachVLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the AppointedForwarder mechanism; thus, it updates RFC 6325.

 
RFC 6442 Location Conveyance for the Session Initiation Protocol
 
Authors:J. Polk, B. Rosen, J. Peterson.
Date:December 2011
Formats:txt json html
Updated by:RFC 8262, RFC 8787
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6442
This document defines an extension to the Session Initiation Protocol(SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of theLocation Target.
 
RFC 6443 Framework for Emergency Calling Using Internet Multimedia
 
Authors:B. Rosen, H. Schulzrinne, J. Polk, A. Newton.
Date:December 2011
Formats:txt json html
Updated by:RFC 7852
Status:INFORMATIONAL
DOI:10.17487/RFC 6443
The IETF has standardized various aspects of placing emergency calls.This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.
 
RFC 6455 The WebSocket Protocol
 
Authors:I. Fette, A. Melnikov.
Date:December 2011
Formats:txt html json
Updated by:RFC 7936, RFC 8307, RFC 8441
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6455
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., usingXMLHttpRequest or <iframe&rt;s and long polling).
 
RFC 6460 Suite B Profile for Transport Layer Security (TLS)
 
Authors:M. Salter, R. Housley.
Date:January 2012
Formats:txt html json
Obsoletes:RFC 5430
Updated by:RFC 8996
Status:HISTORIC
DOI:10.17487/RFC 6460
The United States government has published guidelines for "NSA SuiteB Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully compliant with Suite B.
 
RFC 6478 Pseudowire Status for Static Pseudowires
 
Authors:L. Martini, G. Swallow, G. Heron, M. Bocci.
Date:May 2012
Formats:txt html json
Updates:RFC 5885
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6478
This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allowsPW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection(BFD) is used to convey PW status-signaling information.
 
RFC 6487 A Profile for X.509 PKIX Resource Certificates
 
Authors:G. Huston, G. Michaelson, R. Loomans.
Date:February 2012
Formats:txt json html
Updated by:RFC 7318, RFC 8209
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6487
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and CertificateRevocation List (CRL) syntax in the Resource Public KeyInfrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure.
 
RFC 6513 Multicast in MPLS/BGP IP VPNs
 
Authors:E. Rosen, Ed., R. Aggarwal, Ed..
Date:February 2012
Formats:txt json html
Updated by:RFC 7582, RFC 7900, RFC 7988
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6513
In order for IP multicast traffic within a BGP/MPLS IP VPN (VirtualPrivate Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN ServiceProvider. These protocols and procedures are specified in this document.
 
RFC 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
 
Authors:R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter.
Date:February 2012
Formats:txt html json
Updated by:RFC 6515, RFC 6625, RFC 7385, RFC 7441, RFC 7582, RFC 7899, RFC 7900, RFC 7902, RFC 7988, RFC 8534, RFC 9081
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6514
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGPIP VPNs, as specified in RFC 6513.
 
RFC 6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
 
Authors:R. Seggelmann, M. Tuexen, M. Williams.
Date:February 2012
Formats:txt html json
Updated by:RFC 8447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6520
This document describes the Heartbeat Extension for the TransportLayer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.

 
RFC 6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
 
Authors:M. Kucherawy, Ed..
Date:January 2012
Formats:txt json html
Obsoletes:RFC 3462
Updated by:RFC 6533
Also:STD 0073
Status:INTERNET STANDARD
DOI:10.17487/RFC 6522
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.

This memo obsoletes "The Multipart/Report Content Type for theReporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic".

 
RFC 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
 
Authors:T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander.
Date:March 2012
Formats:txt json html
Updated by:RFC 9008, RFC 9010
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6550
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside theLLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks(RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.
 
RFC 6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
 
Authors:J. Hui, JP. Vasseur.
Date:March 2012
Formats:txt html json
Updated by:RFC 9008
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6553
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes theRPL Option for use among RPL routers to include such routing information.
 
RFC 6572 RADIUS Support for Proxy Mobile IPv6
 
Authors:F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic.
Date:June 2012
Formats:txt html json
Updated by:RFC 8044
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6572
This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-basedAAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting.
 
RFC 6591 Authentication Failure Reporting Using the Abuse Reporting Format
 
Authors:H. Fontana.
Date:April 2012
Formats:txt json html
Updated by:RFC 6692
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6591
This memo registers an extension report type for the Abuse ReportingFormat (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks.
 
RFC 6613 RADIUS over TCP
 
Authors:A. DeKok.
Date:May 2012
Formats:txt html json
Updated by:RFC 7930
Status:EXPERIMENTAL
DOI:10.17487/RFC 6613
The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over theTransmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security(RADIUS/TLS). It permits TCP to be used as a transport protocol forRADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security.
 
RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS
 
Authors:S. Winter, M. McCauley, S. Venaas, K. Wierenga.
Date:May 2012
Formats:txt json html
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 6614
This document specifies a transport profile for RADIUS usingTransport Layer Security (TLS) over TCP as the transport protocol.This enables dynamic trust relationships between RADIUS servers.
 
RFC 6625 Wildcards in Multicast VPN Auto-Discovery Routes
 
Authors:E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu.
Date:May 2012
Formats:txt json html
Updates:RFC 6514
Updated by:RFC 7582, RFC 7900, RFC 8534
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6625
In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network.The base specifications for MVPN define BGP multicast VPN "auto- discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto- discovery route can refer to multiple customer flows or even to all customer flows.
 
RFC 6638 Scheduling Extensions to CalDAV
 
Authors:C. Daboo, B. Desruisseaux.
Date:June 2012
Formats:txt json html
Updates:RFC 4791, RFC 5546
Updated by:RFC 7953
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6638
This document defines extensions to the Calendaring Extensions toWebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.
 
RFC 6665 SIP-Specific Event Notification
 
Authors:A.B. Roach.
Date:July 2012
Formats:txt html json
Obsoletes:RFC 3265
Updates:RFC 3261, RFC 4660
Updated by:RFC 7621
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6665
This document describes an extension to the Session InitiationProtocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

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

This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document.

 
RFC 6679 Explicit Congestion Notification (ECN) for RTP over UDP
 
Authors:M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg.
Date:August 2012
Formats:txt html json
Updated by:RFC 8311
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6679
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT(STUN) extension used in the optional initialisation method usingInteractive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined.
 
RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
 
Authors:P. Hoffman, J. Schlyter.
Date:August 2012
Formats:txt html json
Updated by:RFC 7218, RFC 7671, RFC 8749
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6698
Encrypted communication on the Internet often uses Transport LayerSecurity (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.
 
RFC 6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules
 
Authors:T. Polk, P. Saint-Andre.
Date:August 2012
Formats:txt json html
Updated by:RFC 8717
Status:INFORMATIONAL
DOI:10.17487/RFC 6702
The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries.
 
RFC 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
 
Authors:T. Kause, M. Peylo.
Date:September 2012
Formats:txt json html
Updates:RFC 4210
Updated by:RFC 9480
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6712
This document describes how to layer the Certificate ManagementProtocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein.
 
RFC 6716 Definition of the Opus Audio Codec
 
Authors:JM. Valin, K. Vos, T. Terriberry.
Date:September 2012
Formats:txt json html
Updated by:RFC 8251
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6716
This document defines the Opus interactive speech and audio codec.Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and theModified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music.
 
RFC 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
 
Authors:C. Pignataro, R. Asati.
Date:August 2012
Formats:txt html json
Updates:RFC 5036
Updated by:RFC 7552
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6720
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for theLabel Distribution Protocol (LDP).

This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036.

 
RFC 6733 Diameter Base Protocol
 
Authors:V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed..
Date:October 2012
Formats:txt json html
Obsoletes:RFC 3588, RFC 5719
Updated by:RFC 7075, RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6733
The Diameter base protocol is intended to provide an Authentication,Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by allDiameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations.
 
RFC 6739 Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol
 
Authors:H. Schulzrinne, H. Tschofenig.
Date:October 2012
Formats:txt html json
Updated by:RFC 8996
Status:EXPERIMENTAL
DOI:10.17487/RFC 6739
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriatePublic Safety Answering Point (PSAP) for emergency services.

The <mapping&rt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform ResourceIdentifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping&rt; elements between two entities. Exchanging cached <mapping&rt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping&rt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol.

 
RFC 6749 The OAuth 2.0 Authorization Framework
 
Authors:D. Hardt, Ed..
Date:October 2012
Formats:txt json html
Obsoletes:RFC 5849
Updated by:RFC 8252, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6749
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.
 
RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage
 
Authors:M. Jones, D. Hardt.
Date:October 2012
Formats:txt json html
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6750
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
 
RFC 6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
 
Authors:Y. Cai, L. Wei, H. Ou, V. Arya, S. Jethwani.
Date:October 2012
Formats:txt json html
Updated by:RFC 8736, RFC 9436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6754
A Protocol Independent Multicast (PIM) router uses the Reverse PathForwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources.This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics.
 
RFC 6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines
 
Authors:S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed..
Date:September 2012
Formats:txt html json
Obsoletes:RFC 3356
Updated by:RFC 9141
Status:INFORMATIONAL
DOI:10.17487/RFC 6756
This document provides guidance to aid in the understanding of collaboration on standards development between the TelecommunicationStandardization Sector of the International Telecommunication Union(ITU-T) and the Internet Engineering Task Force (IETF) of theInternet Society (ISOC). It is an update of and obsoletes RFC 3356.The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T ASeries Supplement 3 (07/2012).

Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to theITU-T A-Series of Recommendations.

 
RFC 6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6
 
Authors:S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur.
Date:October 2012
Formats:txt html json
Updated by:RFC 7563
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6757
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6.
 
RFC 6763 DNS-Based Service Discovery
 
Authors:S. Cheshire, M. Krochmal.
Date:February 2013
Formats:txt html json
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6763
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standardDNS queries. This mechanism is referred to as DNS-based ServiceDiscovery, or DNS-SD.
 
RFC 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
 
Authors:Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann.
Date:November 2012
Formats:txt json html
Updates:RFC 4944
Updated by:RFC 8505, RFC 8929, RFC 9010
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6775
The IETF work in IPv6 over Low-power Wireless Personal Area Network(6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here.
 
RFC 6790 The Use of Entropy Labels in MPLS Forwarding
 
Authors:K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong.
Date:November 2012
Formats:txt json html
Updates:RFC 3031, RFC 3107, RFC 3209, RFC 5036
Updated by:RFC 7274, RFC 7447, RFC 8012
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6790
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing acrossMPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036.
 
RFC 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol
 
Authors:R. Bush, R. Austein.
Date:January 2013
Formats:txt html json
Updated by:RFC 8210
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6810
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers.
 
RFC 6811 BGP Prefix Origin Validation
 
Authors:P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein.
Date:January 2013
Formats:txt html json
Updated by:RFC 8481, RFC 8893
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6811
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AutonomousSystem (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement.
 
RFC 6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
 
Authors:IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala.
Date:January 2013
Formats:txt json html
Updated by:RFC 7438
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6826
Consider an IP multicast tree, constructed by Protocol IndependentMulticast (PIM), that needs to pass through an MPLS domain in whichMultipoint LDP (mLDP) point-to-multipoint and/or multipoint-to- multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs.
 
RFC 6830 The Locator/ID Separation Protocol (LISP)
 
Authors:D. Farinacci, V. Fuller, D. Meyer, D. Lewis.
Date:January 2013
Formats:txt html json
Obsoleted by:RFC 9300, RFC 9301
Updated by:RFC 8113
Status:EXPERIMENTAL
DOI:10.17487/RFC 6830
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.

Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop.

 
RFC 6839 Additional Media Type Structured Syntax Suffixes
 
Authors:T. Hansen, A. Melnikov.
Date:January 2013
Formats:txt html json
Updates:RFC 3023
Updated by:RFC 7303
Status:INFORMATIONAL
DOI:10.17487/RFC 6839
A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json","+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix.
 
RFC 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC)
 
Authors:S. Weiler, Ed., D. Blacka, Ed..
Date:February 2013
Formats:txt json html
Updates:RFC 4033, RFC 4034, RFC 4035, RFC 5155
Updated by:RFC 8749
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6840
This document is a collection of technical clarifications to the DNSSecurity (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.

This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of theDNSSEC specification.

 
RFC 6870 Pseudowire Preferential Forwarding Status Bit
 
Authors:P. Muley, Ed., M. Aissaoui, Ed..
Date:February 2013
Formats:txt json html
Updates:RFC 4447
Updated by:RFC 7771
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6870
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured betweenProvider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes inMulti-Segment Pseudowire (MS-PW) applications.

In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.

In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.

Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.

 
RFC 6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
 
Authors:G. Salgueiro, V. Gurbani, A. B. Roach.
Date:February 2013
Formats:txt html json
Updated by:RFC 7355
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6873
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.
 
RFC 6881 Best Current Practice for Communications Services in Support of Emergency Calling
 
Authors:B. Rosen, J. Polk.
Date:March 2013
Formats:txt json html
Updated by:RFC 7840, RFC 7852
Also:BCP 0181
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6881
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.
 
RFC 6887 Port Control Protocol (PCP)
 
Authors:D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk.
Date:April 2013
Formats:txt html json
Updated by:RFC 7488, RFC 7652, RFC 7843
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6887
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by aNetwork Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
 
RFC 6890 Special-Purpose IP Address Registries
 
Authors:M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman.
Date:April 2013
Formats:txt json html
Obsoletes:RFC 4773, RFC 5156, RFC 5735, RFC 5736
Updated by:RFC 8190
Also:BCP 0153
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6890
This memo reiterates the assignment of an IPv4 address block(192.0.0.0/24) to IANA. It also instructs IANA to restructure itsIPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special- purpose address blocks, maintaining a common set of information regarding each address block.

This memo obsoletes RFCs 4773, 5156, 5735, and 5736.

 
RFC 6926 DHCPv4 Bulk Leasequery
 
Authors:K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz.
Date:April 2013
Formats:txt html json
Updated by:RFC 7724
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6926
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
 
RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
 
Authors:M. Tuexen, R. Stewart.
Date:May 2013
Formats:txt html json
Updated by:RFC 8899
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6951
This document describes a simple method of encapsulating StreamControl Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacyNATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.

Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or ingress) endpoints.

 
RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
 
Authors:S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
Date:June 2013
Formats:txt html json
Obsoletes:RFC 2560, RFC 6277
Updates:RFC 5912
Updated by:RFC 8954
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6960
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CertificateRevocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
 
RFC 6987 OSPF Stub Router Advertisement
 
Authors:A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson.
Date:September 2013
Formats:txt json html
Obsoletes:RFC 3137
Updated by:RFC 8770
Status:INFORMATIONAL
DOI:10.17487/RFC 6987
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.

This document obsoletes RFC 3137.

 
RFC 7001 Message Header Field for Indicating Message Authentication Status
 
Authors:M. Kucherawy.
Date:September 2013
Formats:txt json html
Obsoletes:RFC 5451, RFC 6577
Obsoleted by:RFC 7601
Updated by:RFC 7410
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7001
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.
 
RFC 7030 Enrollment over Secure Transport
 
Authors:M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed..
Date:October 2013
Formats:txt json html
Updated by:RFC 8951, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7030
This document profiles certificate enrollment for clients usingCertificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport(EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority(CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.
 
RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
 
Authors:T. Savolainen, J. Korhonen, D. Wing.
Date:November 2013
Formats:txt html json
Updated by:RFC 8880
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7050
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-knownIPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments.
 
RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
 
Authors:H. Singh, W. Beebee, C. Donley, B. Stark.
Date:November 2013
Formats:txt html json
Obsoletes:RFC 6204
Updated by:RFC 9096
Status:INFORMATIONAL
DOI:10.17487/RFC 7084
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 RapidDeployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-StackLite (DS-Lite) are covered in the document. The document obsoletesRFC 6204.
 
RFC 7110 Return Path Specified Label Switched Path (LSP) Ping
 
Authors:M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord.
Date:January 2014
Formats:txt html json
Updated by:RFC 7737
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7110
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.
 
RFC 7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element
 
Authors:K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim.
Date:February 2014
Formats:txt html json
Updates:RFC 5810
Updated by:RFC 7391
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7121
This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) NetworkElement (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.
 
RFC 7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
 
Authors:F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan.
Date:March 2014
Formats:txt html json
Updates:RFC 4328
Updated by:RFC 7892
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7139
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channelData Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.

This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.

 
RFC 7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path
 
Authors:L. Jin, F. Jounay, IJ. Wijnands, N. Leymann.
Date:March 2014
Formats:txt json html
Updated by:RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7140
This document introduces a hub and spoke multipoint (HSMP) LabelSwitched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.
 
RFC 7153 IANA Registries for BGP Extended Communities
 
Authors:E. Rosen, Y. Rekhter.
Date:March 2014
Formats:txt html json
Updates:RFC 4360, RFC 5701
Updated by:RFC 9184
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7153
This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the"IANA Considerations" sections of future protocol specifications.This document updates RFC 4360 and RFC 5701.
 
RFC 7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1
 
Authors:H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna.
Date:May 2014
Formats:txt json html
Updated by:RFC 9427
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7170
This document defines the Tunnel Extensible Authentication Protocol(TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using theTransport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.
 
RFC 7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
 
Authors:V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee.
Date:May 2014
Formats:txt json html
Updated by:RFC 8564
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7175
This document specifies use of the Bidirectional Forwarding Detection(BFD) protocol in Routing Bridge (RBridge) campuses based on theRBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.

BFD is a widely deployed Operations, Administration, and Maintenance(OAM) mechanism in IP and MPLS networks, using UDP and AssociatedChannel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.

 
RFC 7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency
 
Authors:D. Eastlake 3rd, R. Perlman, A. Ghanwani, H. Yang, V. Manral.
Date:May 2014
Formats:txt html json
Obsoletes:RFC 6327
Updates:RFC 6325
Updated by:RFC 7780, RFC 8139, RFC 8249, RFC 8377, RFC 8564
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7177
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network(LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System(IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.
 
RFC 7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
 
Authors:D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward.
Date:May 2014
Formats:txt json html
Updated by:RFC 7978
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7178
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the TransparentInterconnection of Lots of Links (TRILL) protocol.
 
RFC 7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension
 
Authors:D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler.
Date:May 2014
Formats:txt json html
Updates:RFC 6325
Updated by:RFC 7780
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7179
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILLHeader extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.
 
RFC 7181 The Optimized Link State Routing Protocol Version 2
 
Authors:T. Clausen, C. Dearlove, P. Jacquet, U. Herberg.
Date:April 2014
Formats:txt json html
Updated by:RFC 7183, RFC 7187, RFC 7188, RFC 7466
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7181
This specification describes version 2 of the Optimized Link StateRouting Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).
 
RFC 7186 Security Threats for the Neighborhood Discovery Protocol (NHDP)
 
Authors:J. Yi, U. Herberg, T. Clausen.
Date:April 2014
Formats:txt html json
Updated by:RFC 7985
Status:INFORMATIONAL
DOI:10.17487/RFC 7186
This document analyzes common security threats of the NeighborhoodDiscovery Protocol (NHDP) and describes their potential impacts onMobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described.
 
RFC 7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
 
Authors:C. Dearlove, T. Clausen.
Date:April 2014
Formats:txt json html
Updates:RFC 6130, RFC 7181
Updated by:RFC 7722
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7188
This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updatesRFC 7181 (OLSRv2) and RFC 6130 (NHDP).
 
RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
 
Authors:S. Kitterman.
Date:April 2014
Formats:txt json html
Obsoletes:RFC 4408
Updated by:RFC 7372, RFC 8553, RFC 8616
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7208
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrativeManagement Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.

This document obsoletes RFC 4408.

 
RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
 
Authors:R. Fielding, Ed., J. Reschke, Ed..
Date:June 2014
Formats:txt json html
Obsoletes:RFC 2145, RFC 2616
Obsoleted by:RFC 9110, RFC 9112
Updates:RFC 2817, RFC 2818
Updated by:RFC 8615
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7230
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" UniformResource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
 
RFC 7240 Prefer Header for HTTP
 
Authors:J. Snell.
Date:June 2014
Formats:txt html json
Updated by:RFC 8144
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7240
This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.
 
RFC 7241 The IEEE 802/IETF Relationship
 
Authors:S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed..
Date:July 2014
Formats:txt html json
Obsoletes:RFC 4441
Updated by:RFC 9141
Status:INFORMATIONAL
DOI:10.17487/RFC 7241
This document describes the standardization cooperation betweenProject 802 of the Institute of Electrical and Electronics Engineers(IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

 
RFC 7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
 
Authors:IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura.
Date:June 2014
Formats:txt json html
Updated by:RFC 7438
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7246
An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non- label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IPMDT, then convert it to an MPLS Multipoint Label Switched Path(MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region.Other documents specify the procedures for building such a hybridMDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label DistributionProtocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.
 
RFC 7252 The Constrained Application Protocol (CoAP)
 
Authors:Z. Shelby, K. Hartke, C. Bormann.
Date:June 2014
Formats:txt json html
Updated by:RFC 7959, RFC 8613, RFC 8974, RFC 9175
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7252
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained(e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks(6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs andInternet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

 
RFC 7265 jCal: The JSON Format for iCalendar
 
Authors:P. Kewisch, C. Daboo, M. Douglass.
Date:May 2014
Formats:txt html json
Updated by:RFC 7529
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7265
This specification defines "jCal", a JSON format for iCalendar data.The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.
 
RFC 7268 RADIUS Attributes for IEEE 802 Networks
 
Authors:B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones.
Date:July 2014
Formats:txt html json
Updates:RFC 3580, RFC 4072
Updated by:RFC 8044
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7268
RFC 3580 provides guidelines for the use of the Remote AuthenticationDial-In User Service (RADIUS) within IEEE 802 local area networks(LANs). This document defines additional attributes for use withinIEEE 802 networks and clarifies the usage of the EAP-Key-NameAttribute and the Called-Station-Id Attribute. This document updatesRFCs 3580 and 4072.
 
RFC 7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators
 
Authors:J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne.
Date:June 2014
Formats:txt html json
Updates:RFC 6378
Updated by:RFC 8234
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7271
This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.

This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and AutomaticProtection Switching (APS) mode.

This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.

This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.

 
RFC 7274 Allocating and Retiring Special-Purpose MPLS Labels
 
Authors:K. Kompella, L. Andersson, A. Farrel.
Date:June 2014
Formats:txt html json
Updates:RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790
Updated by:RFC 9017
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7274
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special- purpose labels" in this document.

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special- purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLSLabel Values" and creates a new registry called the "ExtendedSpecial-Purpose MPLS Label Values" registry.

This document updates a number of previous RFCs that use the term"reserved label". Specifically, this document updates RFCs 3032,3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and6790.

 
RFC 7285 Application-Layer Traffic Optimization (ALTO) Protocol
 
Authors:R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy.
Date:September 2014
Formats:txt html json
Updated by:RFC 9274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7285
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.

This document describes a protocol implementing the ALTO services.Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.

 
RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2)
 
Authors:C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen.
Date:October 2014
Formats:txt json html
Obsoletes:RFC 5996
Updated by:RFC 7427, RFC 7670, RFC 8247, RFC 8983, RFC 9370
Also:STD 0079
Status:INTERNET STANDARD
DOI:10.17487/RFC 7296
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations(SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.
 
RFC 7299 Object Identifier Registry for the PKIX Working Group
 
Authors:R. Housley.
Date:July 2014
Formats:txt html json
Updated by:RFC 9158
Status:INFORMATIONAL
DOI:10.17487/RFC 7299
When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.
 
RFC 7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
 
Authors:S. Friedl, A. Popov, A. Langley, E. Stephan.
Date:July 2014
Formats:txt html json
Updated by:RFC 8447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7301
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.
 
RFC 7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
 
Authors:R. Jesske, K. Drage, C. Holmberg.
Date:July 2014
Formats:txt html json
Obsoletes:RFC 3455
Updated by:RFC 7913, RFC 7976
Status:INFORMATIONAL
DOI:10.17487/RFC 7315
This document describes a set of private header (P-header) SessionInitiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. TheP-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.
 
RFC 7322 RFC Style Guide
 
Authors:H. Flanagan, S. Ginoza.
Date:September 2014
Formats:txt json html
Obsoletes:RFC 2223
Updated by:RFC 7997
Status:INFORMATIONAL
DOI:10.17487/RFC 7322
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.This document obsoletes RFC 2223, "Instructions to RFC Authors".
 
RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
 
Authors:J. Laganier, F. Dupont.
Date:September 2014
Formats:txt html json
Obsoletes:RFC 4843
Updated by:RFC 9374
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7343
This document specifies an updated Overlay Routable CryptographicHash Identifiers (ORCHID) format that obsoletes that in RFC 4843.These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators.They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

 
RFC 7344 Automating DNSSEC Delegation Trust Maintenance
 
Authors:W. Kumari, O. Gudmundsson, G. Barwood.
Date:September 2014
Formats:txt json html
Updated by:RFC 8078
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7344
This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.
 
RFC 7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
 
Authors:C. Holmberg, I. Sedlacek, G. Salgueiro.
Date:August 2014
Formats:txt json html
Updated by:RFC 8842
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7345
This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session DescriptionProtocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).
 
RFC 7370 Updates to the IS-IS TLV Codepoints Registry
 
Authors:L. Ginsberg.
Date:September 2014
Formats:txt json html
Updated by:RFC 9352
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7370
This document recommends some editorial changes to the IANA "IS-ISTLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.
 
RFC 7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points
 
Authors:L. Andersson, G. Swallow.
Date:October 2014
Formats:txt json html
Updates:RFC 6514
Updated by:RFC 8317, RFC 8338
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7385
RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSITunnel) attribute". However, the RFC did not create a correspondingIANA registry.

There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.

 
RFC 7401 Host Identity Protocol Version 2 (HIPv2)
 
Authors:R. Moskowitz, Ed., T. Heer, P. Jokela, T. Henderson.
Date:April 2015
Formats:txt json html
Obsoletes:RFC 5201
Updated by:RFC 8002, RFC 9374
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7401
This document specifies the details of the Host Identity Protocol(HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.

This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

 
RFC 7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents
 
Authors:M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann.
Date:February 2015
Formats:txt json html
Obsoletes:RFC 4614
Updated by:RFC 7805
Status:INFORMATIONAL
DOI:10.17487/RFC 7414
This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

This document obsoletes RFC 4614.

 
RFC 7432 BGP MPLS-Based Ethernet VPN
 
Authors:A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx.
Date:February 2015
Formats:txt html json
Updated by:RFC 8584, RFC 9161
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7432
This document describes procedures for BGP MPLS-based Ethernet VPNs(EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".
 
RFC 7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:M. Kucherawy, Ed..
Date:January 2015
Formats:txt html json
Obsoletes:RFC 3777, RFC 5078, RFC 5633, RFC 5680, RFC 6859
Obsoleted by:RFC 8713
Updated by:RFC 8318
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7437
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.
 
RFC 7450 Automatic Multicast Tunneling
 
Authors:G. Bumgardner.
Date:February 2015
Formats:txt html json
Updated by:RFC 8777
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7450
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.

The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.

 
RFC 7465 Prohibiting RC4 Cipher Suites
 
Authors:A. Popov.
Date:February 2015
Formats:txt html json
Updates:RFC 5246, RFC 4346, RFC 2246
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7465
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.
 
RFC 7473 Controlling State Advertisements of Non-negotiated LDP Applications
 
Authors:K. Raza, S. Boutros.
Date:March 2015
Formats:txt json html
Updated by:RFC 8223
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7473
There is no capability negotiation done for Label DistributionProtocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.
 
RFC 7484 Finding the Authoritative Registration Data (RDAP) Service
 
Authors:M. Blanchet.
Date:March 2015
Formats:txt html json
Obsoleted by:RFC 9224
Updated by:RFC 8521
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7484
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers.
 
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
 
Authors:M. Kucherawy, Ed., E. Zwicky, Ed..
Date:March 2015
Formats:txt html json
Updated by:RFC 8553, RFC 8616
Status:INFORMATIONAL
DOI:10.17487/RFC 7489
Domain-based Message Authentication, Reporting, and Conformance(DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits:Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

 
RFC 7519 JSON Web Token (JWT)
 
Authors:M. Jones, J. Bradley, N. Sakimura.
Date:May 2015
Formats:txt html json
Updated by:RFC 7797, RFC 8725
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7519
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSONWeb Signature (JWS) structure or as the plaintext of a JSON WebEncryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted.
 
RFC 7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
 
Authors:Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad.
Date:May 2015
Formats:txt html json
Updated by:RFC 8534
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7524
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra- area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled usingP2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or(point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may beBGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.
 
RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
 
Authors:Y. Sheffer, R. Holz, P. Saint-Andre.
Date:May 2015
Formats:txt html json
Obsoleted by:RFC 9325
Updated by:RFC 8996
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7525
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS.The recommendations are applicable to the majority of use cases.
 
RFC 7530 Network File System (NFS) Version 4 Protocol
 
Authors:T. Haynes, Ed., D. Noveck, Ed..
Date:March 2015
Formats:txt html json
Obsoletes:RFC 3530
Updated by:RFC 7931, RFC 8587
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7530
The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol.In addition, support for strong security (and its negotiation),COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

This document, together with the companion External DataRepresentation (XDR) description document, RFC 7531, obsoletes RFC3530 as the definition of the NFS version 4 protocol.

 
RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2)
 
Authors:M. Belshe, R. Peon, M. Thomson, Ed..
Date:May 2015
Formats:txt json html
Obsoleted by:RFC 9113
Updated by:RFC 8740
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7540
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, theHTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

 
RFC 7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
 
Authors:F. Zhang, Ed., R. Jing, R. Gandhi, Ed..
Date:May 2015
Formats:txt json html
Updated by:RFC 8537
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7551
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label SwitchedPaths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. TheREVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.
 
RFC 7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates
 
Authors:D. Thakore.
Date:July 2015
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 7562
This document specifies the use of Digital Transmission ContentProtection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containingDTCP certificates issued by the Digital Transmission LicensingAdministrator (DTLA).
 
RFC 7568 Deprecating Secure Sockets Layer Version 3.0
 
Authors:R. Barnes, M. Thomson, A. Pironti, A. Langley.
Date:June 2015
Formats:txt json html
Updates:RFC 5246
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7568
The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, TransportLayer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

 
RFC 7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels
 
Authors:E. Rosen, IJ. Wijnands, Y. Cai, A. Boers.
Date:July 2015
Formats:txt html json
Updates:RFC 6513, RFC 6514, RFC 6625
Updated by:RFC 8534
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7582
A set of prior RFCs specify procedures for supporting multicast inBGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.
 
RFC 7595 Guidelines and Registration Procedures for URI Schemes
 
Authors:D. Thaler, Ed., T. Hansen, T. Hardie.
Date:June 2015
Formats:txt json html
Obsoletes:RFC 4395
Updated by:RFC 8615
Also:BCP 0035
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7595
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of UniformResource Identifier (URI) schemes. It obsoletes RFC 4395.
 
RFC 7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients
 
Authors:T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng.
Date:July 2015
Formats:txt json html
Updated by:RFC 8539
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7598
This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices.Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.
 
RFC 7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format
 
Authors:C. Dearlove, T. Clausen.
Date:September 2015
Formats:txt json html
Updates:RFC 5444
Updated by:RFC 7722
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7631
This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork(MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.

This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes toRFC 5444.

 
RFC 7641 Observing Resources in the Constrained Application Protocol (CoAP)
 
Authors:K. Hartke.
Date:September 2015
Formats:txt html json
Updated by:RFC 8323
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7641
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to"observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.
 
RFC 7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
 
Authors:T. Hansen.
Date:November 2015
Formats:txt json html
Updates:RFC 5802
Updated by:RFC 9266
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7677
This document registers the Simple Authentication and Security Layer(SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.
 
RFC 7683 Diameter Overload Indication Conveyance
 
Authors:J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand.
Date:October 2015
Formats:txt json html
Updated by:RFC 8581
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7683
This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance(DOIC).
 
RFC 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
 
Authors:H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray.
Date:March 2016
Formats:txt html json
Obsoleted by:RFC 9552
Updated by:RFC 9029
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7752
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.

This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.

Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs).

 
RFC 7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
 
Authors:B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng.
Date:March 2016
Formats:txt json html
Obsoletes:RFC 4601
Updated by:RFC 8736, RFC 9436
Also:STD 0083
Status:INTERNET STANDARD
DOI:10.17487/RFC 7761
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.

This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM MulticastBorder Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.

 
RFC 7766 DNS Transport over TCP - Implementation Requirements
 
Authors:J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, D. Wessels.
Date:March 2016
Formats:txt html json
Obsoletes:RFC 5966
Updates:RFC 1035, RFC 1123
Updated by:RFC 8490, RFC 9103
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7766
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.This document obsoletes RFC 5966 and therefore updates RFC 1035 andRFC 1123.
 
RFC 7776 IETF Anti-Harassment Procedures
 
Authors:P. Resnick, A. Farrel.
Date:March 2016
Formats:txt html json
Updates:RFC 2418
Updated by:RFC 8716
Also:BCP 0025
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 7776
IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.

This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.

 
RFC 7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
 
Authors:D. Eastlake 3rd, M. Zhang, R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta.
Date:February 2016
Formats:txt json html
Obsoletes:RFC 7180
Updates:RFC 6325, RFC 7177, RFC 7179
Updated by:RFC 8249
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7780
Since the publication of the TRILL (Transparent Interconnection ofLots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station AddressDistribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs6325, 7177, and 7179.
 
RFC 7788 Home Networking Control Protocol
 
Authors:M. Stenberg, S. Barth, P. Pfister.
Date:April 2016
Formats:txt json html
Updated by:RFC 8375
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7788
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.
 
RFC 7841 RFC Streams, Headers, and Boilerplates
 
Authors:J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed..
Date:May 2016
Formats:txt json html
Obsoletes:RFC 5741
Updated by:RFC 9280
Status:INFORMATIONAL
DOI:10.17487/RFC 7841
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.
 
RFC 7845 Ogg Encapsulation for the Opus Audio Codec
 
Authors:T. Terriberry, R. Lee, R. Giles.
Date:April 2016
Formats:txt json html
Updates:RFC 5334
Updated by:RFC 8486
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7845
This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.
 
RFC 7854 BGP Monitoring Protocol (BMP)
 
Authors:J. Scudder, Ed., R. Fernando, S. Stuart.
Date:June 2016
Formats:txt json html
Updated by:RFC 8671, RFC 9069, RFC 9515
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7854
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.BMP is not suitable for use as a routing protocol.
 
RFC 7858 Specification for DNS over Transport Layer Security (TLS)
 
Authors:Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman.
Date:May 2016
Formats:txt json html
Updated by:RFC 8310
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7858
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.

This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.

 
RFC 7862 Network File System (NFS) Version 4 Minor Version 2 Protocol
 
Authors:T. Haynes.
Date:November 2016
Formats:txt html json
Updated by:RFC 8178
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7862
This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O)Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.
 
RFC 7873 Domain Name System (DNS) Cookies
 
Authors:D. Eastlake 3rd, M. Andrews.
Date:May 2016
Formats:txt html json
Updated by:RFC 9018
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7873
DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNSCookies are tolerant of NAT, NAT-PT (Network Address Translation -Protocol Translation), and anycast and can be incrementally deployed.(Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally trackInternet users.)
 
RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs
 
Authors:Y. Rekhter, Ed., E. Rosen, Ed., R. Aggarwal, Y. Cai, T. Morin.
Date:June 2016
Formats:txt json html
Updates:RFC 6513, RFC 6514, RFC 6625
Updated by:RFC 8534
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7900
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN(Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.
 
RFC 7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure
 
Authors:G. Huston, G. Michaelson, Ed..
Date:August 2016
Formats:txt json html
Obsoletes:RFC 6485
Updated by:RFC 8208, RFC 8608
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7935
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.
 
RFC 7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
 
Authors:M. Westerlund, B. Burman, R. Even, M. Zanaty.
Date:August 2016
Formats:txt html json
Updated by:RFC 8843, RFC 9143
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7941
Source Description (SDES) items are normally transported in the RTPControl Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.
 
RFC 7950 The YANG 1.1 Data Modeling Language
 
Authors:M. Bjorklund, Ed..
Date:August 2016
Formats:txt html json
Updated by:RFC 8342, RFC 8526
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7950
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol(NETCONF).
 
RFC 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP)
 
Authors:C. Bormann, Z. Shelby, Ed..
Date:August 2016
Formats:txt html json
Updates:RFC 7252
Updated by:RFC 8323
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7959
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security(DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.

Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.

A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updatesRFC 7252.

 
RFC 7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)
 
Authors:M. Petit-Huguenin, G. Salgueiro.
Date:September 2016
Formats:txt json html
Updates:RFC 5764
Updated by:RFC 9443
Status:PROPOSED STANDARD
DOI:10.17487/RFC 7983
This document defines how Datagram Transport Layer Security (DTLS),Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTPExtension for DTLS"), which suffered from four issues described and fixed in this document.

This document updates RFC 5764.

 
RFC 8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
 
Authors:J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma.
Date:December 2016
Formats:txt html json
Updated by:RFC 9388
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8008
This document captures the semantics of the "Footprint andCapabilities Advertisement" part of the Content Delivery NetworkInterconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for theCDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.
 
RFC 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures
 
Authors:K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen.
Date:March 2017
Formats:txt html json
Obsoletes:RFC 4379, RFC 6424, RFC 6829, RFC 7537
Updates:RFC 1122
Updated by:RFC 8611, RFC 9041
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8029
This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) LabelSwitched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.

This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updatesRFC 1122.

 
RFC 8040 RESTCONF Protocol
 
Authors:A. Bierman, M. Bjorklund, K. Watsen.
Date:January 2017
Formats:txt json html
Updated by:RFC 8527
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8040
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol(NETCONF).
 
RFC 8060 LISP Canonical Address Format (LCAF)
 
Authors:D. Farinacci, D. Meyer, J. Snijders.
Date:February 2017
Formats:txt json html
Updated by:RFC 9306
Status:EXPERIMENTAL
DOI:10.17487/RFC 8060
This document defines a canonical address format encoding used inLocator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.
 
RFC 8085 UDP Usage Guidelines
 
Authors:L. Eggert, G. Fairhurst, G. Shepherd.
Date:March 2017
Formats:txt json html
Obsoletes:RFC 5405
Updated by:RFC 8899
Also:BCP 0145
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8085
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ExplicitCongestion Notification (ECN), Differentiated Services Code Points(DSCPs), and ports.

Because congestion control is critical to the stable operation of theInternet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.

Some guidance is also applicable to the design of other protocols(e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.

This document obsoletes RFC 5405 and adds guidelines for multicastUDP usage.

 
RFC 8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
 
Authors:J. Lennox, C. Holmberg.
Date:March 2017
Formats:txt html json
Obsoletes:RFC 4572
Updated by:RFC 8844
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8122
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

 
RFC 8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header
 
Authors:P. Thubert, Ed., C. Bormann, L. Toutain, R. Cragie.
Date:April 2017
Formats:txt json html
Updated by:RFC 9008, RFC 9035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8138
This specification introduces a new IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of RoutingProtocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.
 
RFC 8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
 
Authors:D. Wessels, W. Kumari, P. Hoffman.
Date:April 2017
Formats:txt html json
Updated by:RFC 8553
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8145
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in aDNSSEC-signed zone.
 
RFC 8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1
 
Authors:C. Lever, Ed., W. Simpson, T. Talpey.
Date:June 2017
Formats:txt json html
Obsoletes:RFC 5666
Updated by:RFC 8797
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8166
This document specifies a protocol for conveying Remote ProcedureCall (RPC) messages on physical transports capable of Remote DirectMemory Access (RDMA). This protocol is referred to as the RPC-over-RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666.
 
RFC 8198 Aggressive Use of DNSSEC-Validated Cache
 
Authors:K. Fujiwara, A. Kato, W. Kumari.
Date:July 2017
Formats:txt html json
Updates:RFC 4035
Updated by:RFC 9077
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8198
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certainDoS attacks in some circumstances.

This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.

 
RFC 8205 BGPsec Protocol Specification
 
Authors:M. Lepinski, Ed., K. Sriram, Ed..
Date:September 2017
Formats:txt html json
Updated by:RFC 8206
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8205
This document describes BGPsec, an extension to the Border GatewayProtocol (BGP) that provides security for the path of AutonomousSystems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates theUPDATE message. The digital signatures provide confidence that everyAS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.
 
RFC 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
 
Authors:P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen.
Date:October 2017
Formats:txt html json
Obsoletes:RFC 7321
Updated by:RFC 9395
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8221
This document replaces RFC 7321, "Cryptographic AlgorithmImplementation Requirements and Usage Guidance for EncapsulatingSecurity Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.
 
RFC 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP)
 
Authors:J. Peterson, C. Jennings, E. Rescorla, C. Wendt.
Date:February 2018
Formats:txt html json
Obsoletes:RFC 4474
Updated by:RFC 8946
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8224
The baseline security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining aSIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.

This document obsoletes RFC 4474.

 
RFC 8226 Secure Telephone Identity Credentials: Certificates
 
Authors:J. Peterson, S. Turner.
Date:February 2018
Formats:txt json html
Updated by:RFC 9118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8226
In order to prevent the impersonation of telephone numbers on theInternet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.
 
RFC 8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
 
Authors:E. Crabbe, I. Minei, J. Medved, R. Varga.
Date:September 2017
Formats:txt html json
Updated by:RFC 8786, RFC 9353
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8231
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and acrossPCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP.

 
RFC 8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
 
Authors:Y. Nir, T. Kivinen, P. Wouters, D. Migault.
Date:September 2017
Formats:txt html json
Obsoletes:RFC 4307
Updates:RFC 7296
Updated by:RFC 9395
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8247
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE) protocol is used to negotiate the IPsec SecurityAssociation (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updatesRFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsecEncapsulating Security Payload (ESP).
 
RFC 8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
 
Authors:M. Tuexen, R. Stewart, R. Jesup, S. Loreto.
Date:November 2017
Formats:txt json html
Updated by:RFC 8899, RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8261
The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocolsIPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, theSCTP associations carried over DTLS can only be single-homed.
 
RFC 8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes
 
Authors:N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen.
Date:December 2017
Formats:txt html json
Updated by:RFC 8690, RFC 9214
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8287
A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of aMultiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture.This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix andIGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

 
RFC 8300 Network Service Header (NSH)
 
Authors:P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed..
Date:January 2018
Formats:txt json html
Updated by:RFC 9451
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8300
This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining(SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).
 
RFC 8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
 
Authors:Q. Zhao, D. Dhody, Ed., R. Palleti, D. King.
Date:November 2017
Formats:txt html json
Obsoletes:RFC 6006
Updated by:RFC 9353
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8306
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE Communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.

This document obsoletes RFC 6006.

 
RFC 8308 Extension Negotiation in the Secure Shell (SSH) Protocol
 
Authors:D. Bider.
Date:March 2018
Formats:txt json html
Updates:RFC 4251, RFC 4252, RFC 4253, RFC 4254
Updated by:RFC 9519
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8308
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially afterSSH key exchange.
 
RFC 8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
 
Authors:K. Moore, C. Newman.
Date:January 2018
Formats:txt json html
Updates:RFC 1939, RFC 2595, RFC 3501, RFC 5068, RFC 6186, RFC 6409
Updated by:RFC 8997
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8314
This specification outlines current recommendations for the use ofTransport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501,5068, 6186, and 6409.
 
RFC 8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
 
Authors:C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed..
Date:February 2018
Formats:txt html json
Updates:RFC 7641, RFC 7959
Updated by:RFC 8974
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8323
The Constrained Application Protocol (CoAP), although inspired byHTTP, was designed to use UDP instead of TCP. The message layer ofCoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS).This document outlines the changes required to use CoAP over TCP,TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.

 
RFC 8325 Mapping Diffserv to IEEE 802.11
 
Authors:T. Szigeti, J. Henry, F. Baker.
Date:February 2018
Formats:txt json html
Updated by:RFC 8622
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8325
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.
 
RFC 8340 YANG Tree Diagrams
 
Authors:M. Bjorklund, L. Berger, Ed..
Date:March 2018
Formats:txt html json
Updated by:RFC 8791
Also:BCP 0215
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8340
This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
 
RFC 8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD)
 
Authors:IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson.
Date:March 2018
Formats:txt html json
Updated by:RFC 8736, RFC 9436
Status:EXPERIMENTAL
DOI:10.17487/RFC 8364
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses aRendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIMFlooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.
 
RFC 8373 Negotiating Human Language in Real-Time Communications
 
Authors:R. Gellens.
Date:May 2018
Formats:txt json html
Updated by:RFC 8865
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8373
Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages.This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).

This document describes the need as well as a solution that uses newSDP media attributes.

 
RFC 8401 Bit Index Explicit Replication (BIER) Support via IS-IS
 
Authors:L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang.
Date:June 2018
Formats:txt html json
Updated by:RFC 9272
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8401
This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.
 
RFC 8402 Segment Routing Architecture
 
Authors:C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir.
Date:July 2018
Formats:txt json html
Updated by:RFC 9256
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8402
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called"segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.

SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by theDestination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

 
RFC 8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
 
Authors:A. Bierman.
Date:October 2018
Formats:txt json html
Obsoletes:RFC 6087
Updated by:RFC 8819
Also:BCP 0216
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8407
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol(NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.
 
RFC 8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
 
Authors:S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick.
Date:July 2018
Formats:txt html json
Updated by:RFC 8664
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8408
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, otherTE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol(PCEP) to allow support for different path setup methods over a givenPCEP session.
 
RFC 8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
 
Authors:S. Josefsson, J. Schaad.
Date:August 2018
Formats:txt html json
Updated by:RFC 9295
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8410
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 andEd448. The key agreement algorithms covered are X25519 and X448.The encoding for public key, private key, and Edwards-curve DigitalSignature Algorithm (EdDSA) structures is provided.
 
RFC 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
 
Authors:Y. Nir, S. Josefsson, M. Pegourie-Gonnard.
Date:August 2018
Formats:txt json html
Obsoletes:RFC 4492
Updated by:RFC 8996
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8422
This document describes key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral EllipticCurve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) andEdwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.

This document obsoletes RFC 4492.

 
RFC 8428 Sensor Measurement Lists (SenML)
 
Authors:C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann.
Date:August 2018
Formats:txt html json
Updated by:RFC 9100
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8428
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists(SenML). Representations are defined in JavaScript Object Notation(JSON), Concise Binary Object Representation (CBOR), ExtensibleMarkup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
 
RFC 8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
 
Authors:P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin.
Date:November 2018
Formats:txt json html
Updated by:RFC 9272
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8444
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). TheBFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in theBIER packet header.

This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.

 
RFC 8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
 
Authors:A. Keranen, C. Holmberg, J. Rosenberg.
Date:July 2018
Formats:txt json html
Obsoletes:RFC 5245
Updated by:RFC 8863
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8445
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based communication. This protocol is calledInteractive Connectivity Establishment (ICE). ICE makes use of theSession Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).

This document obsoletes RFC 5245.

 
RFC 8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)
 
Authors:R. Bush.
Date:September 2018
Formats:txt json html
Updates:RFC 6811
Updated by:RFC 9324
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8481
Deployment of BGP origin validation based on Resource Public KeyInfrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration.This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.
 
RFC 8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
 
Authors:P. Thubert, Ed., E. Nordmark, S. Chakrabarti, C. Perkins.
Date:November 2018
Formats:txt json html
Updates:RFC 6775
Updated by:RFC 8928, RFC 8929, RFC 9010
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8505
This specification updates RFC 6775 -- the Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the RoutingRegistrars performing routing for host routes and/or proxy NeighborDiscovery in a low-power network.
 
RFC 8609 Content-Centric Networking (CCNx) Messages in TLV Format
 
Authors:M. Mosko, I. Solis, C. Wood.
Date:July 2019
Formats:txt html json
Updated by:RFC 9510
Status:EXPERIMENTAL
DOI:10.17487/RFC 8609
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in aTLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.

This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review amongICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.

 
RFC 8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
 
Authors:N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen.
Date:June 2019
Formats:txt html json
Updates:RFC 8029
Updated by:RFC 9041
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8611
This document defines extensions to the MPLS Label Switched Path(LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-CostMultipath (ECMP) over Link Aggregation Group (LAG) interfaces.Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).

This document updates RFC 8029.

 
RFC 8620 The JSON Meta Application Protocol (JMAP)
 
Authors:N. Jenkins, C. Newman.
Date:July 2019
Formats:txt html json
Updated by:RFC 9404
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8620
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.
 
RFC 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC
 
Authors:P. Wouters, O. Sury.
Date:June 2019
Formats:txt html json
Obsoletes:RFC 6944
Updated by:RFC 9157
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8624
The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers andDNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletesRFC 6944.
 
RFC 8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
 
Authors:M. Kucherawy, Ed., R. Hinden, Ed., J. Livingood, Ed..
Date:February 2020
Formats:txt pdf xml html json
Obsoletes:RFC 7437, RFC 8318
Updated by:RFC 9389
Also:BCP 0010
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8713
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC(IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF AdministrativeSupport Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.

This document obsoletes RFC 7437 and RFC 8318.

 
RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation
 
Authors:A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga.
Date:April 2020
Formats:txt json xml html pdf
Updated by:RFC 9441
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8724
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.

SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.

This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.

The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.This document standardizes the exchange over the LPWAN between twoSCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.

 
RFC 8729 The RFC Series and RFC Editor
 
Authors:R. Housley, Ed., L. Daigle, Ed..
Date:February 2020
Formats:txt json pdf xml html
Obsoletes:RFC 4844
Updated by:RFC 9280
Status:INFORMATIONAL
DOI:10.17487/RFC 8729
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. This document obsoletesRFC 4844.
 
RFC 8730 Independent Submission Editor Model
 
Authors:N. Brownlee, Ed., B. Hinden, Ed..
Date:February 2020
Formats:txt xml pdf json html
Obsoletes:RFC 6548
Updated by:RFC 9280
Status:INFORMATIONAL
DOI:10.17487/RFC 8730
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrationLimited Liability Company (LLC).

This version obsoletes RFC 6548 to replace all references to theInternet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.

 
RFC 8762 Simple Two-Way Active Measurement Protocol
 
Authors:G. Mirsky, G. Jun, H. Nydell, R. Foote.
Date:March 2020
Formats:txt json html xml pdf
Updated by:RFC 8972
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8762
This document describes the Simple Two-way Active MeasurementProtocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.
 
RFC 8838 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
 
Authors:E. Ivov, J. Uberti, P. Saint-Andre.
Date:January 2021
Formats:txt pdf xml json html
Updated by:RFC 8863
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8838
This document describes "Trickle ICE", an extension to theInteractive Connectivity Establishment (ICE) protocol that enablesICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.
 
RFC 8955 Dissemination of Flow Specification Rules
 
Authors:C. Loibl, S. Hares, R. Raszuk, D. McPherson, M. Bacher.
Date:December 2020
Formats:txt pdf xml json html
Obsoletes:RFC 5575, RFC 7674
Updated by:RFC 8956, RFC 9117, RFC 9184
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8955
This document defines a Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic FlowSpecifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the FlowSpecification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.

This document obsoletes both RFC 5575 and RFC 7674.

 
RFC 8967 MAC Authentication for the Babel Routing Protocol
 
Authors:C. Dô, W. Kolodziejak, J. Chroboczek.
Date:January 2021
Formats:txt pdf xml html json
Obsoletes:RFC 7298
Updated by:RFC 9467
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8967
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance.This document obsoletes RFC 7298.
 
RFC 8999 Version-Independent Properties of QUIC
 
Authors:M. Thomson.
Date:May 2021
Formats:txt json pdf xml html
Updated by:RFC 9368
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8999
This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.
 
RFC 9052 CBOR Object Signing and Encryption (COSE): Structures and Process
 
Authors:J. Schaad.
Date:August 2022
Formats:txt xml pdf html json
Obsoletes:RFC 8152
Updated by:RFC 9338
Also:STD 0096
Status:INTERNET STANDARD
DOI:10.17487/RFC 9052
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

This document, along with RFC 9053, obsoletes RFC 8152.

 
RFC 9085 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
 
Authors:S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen.
Date:August 2021
Formats:txt xml json pdf html
Updated by:RFC 9356
Status:PROPOSED STANDARD
DOI:10.17487/RFC 9085
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called"segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.

This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) address family in order to carry SR information via BGP.

 
RFC 9127 YANG Data Model for Bidirectional Forwarding Detection (BFD)
 
Authors:R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky.
Date:October 2021
Formats:txt html pdf xml json
Updated by:RFC 9314
Status:PROPOSED STANDARD
DOI:10.17487/RFC 9127
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).

The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342).

 
RFC 9202 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
Authors:S. Gerdes, O. Bergmann, C. Bormann, G. Selander, L. Seitz.
Date:August 2022
Formats:txt json pdf xml html
Updated by:RFC 9430
Status:PROPOSED STANDARD
DOI:10.17487/RFC 9202
This specification defines a profile of the Authentication andAuthorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.
 
RFC 9298 Proxying UDP in HTTP
 
Authors:D. Schinazi.
Date:August 2022
Formats:txt json html xml pdf
Updated by:RFC 9484
Status:PROPOSED STANDARD
DOI:10.17487/RFC 9298
This document describes how to proxy UDP in HTTP, similar to how theHTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy.
 
RFC 9363 A YANG Data Model for Static Context Header Compression (SCHC)
 
Authors:A. Minaburo, L. Toutain.
Date:March 2023
Formats:txt json html xml pdf
Updated by:RFC 9441
Status:PROPOSED STANDARD
DOI:10.17487/RFC 9363
This document describes a YANG data model for the Static ContextHeader Compression (SCHC) compression and fragmentation Rules.

This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set ofRules or to modify the parameters of some Rules.